[Bug gas/1433] IA64 assembler generates bad 2.6.9 Linux kernel.
--- Additional Comments From wilson at specifix dot com 2005-10-07 01:18 --- Subject: Re: IA64 assembler generates bad 2.6.9 Linux kernel. On Thu, 2005-10-06 at 16:24, hjl at lucon dot org wrote: > - 0001004d R_IA64_PCREL32LSB .text + 2 > + 0001004d R_IA64_PCREL32LSB .text + 1 This seems to be an old debate reborn. When we have relocs, tags, debug info, whatever that applies to a long (2-slot) instruction, do we point at slot 1 or slot 2? old-as is pointing at slot 2. new-as is pointing at slot 1. One could argue that new-as is actually more correct in this case, because the tag should be pointing before the long instruction, and hence must be pointing at slot 1. Richard's patch broke this because he moved the tag_fixups code in emit_one_bundle before the code that increments i when required_unit == IA64_UNIT_L. So in the old code, we are setting debug info and unwind info to point to slot 1 (before we increment i), and tags and relocs to point to slot 2 (after we increment i). In the new code, we are setting debug info, unwind info, and tags to point to slot 1 (before we increment i), and relocs to point to slot 2 (after we increment i). At least we are consistently inconsistent. Questions to ask at this point are: 1) Why did Richard move the code? Did he run into some problem with the debug info not matching the tags? 2) Why does the kernel care whether we use slot 1 or slot 2 here? Maybe the kernel can be fixed? It seems wrong for the kernel to insist that a tag must point into the middle of a long instruction. 3) Will this change affect gdb? 4) What does IAS do in this case? 5) Maybe we should fix relocs to point at slot 1 and then be completely consistent? This is an ABI change unfortunately, though perhaps we can hide it by making the linker accept either one for a while. -- http://sourceware.org/bugzilla/show_bug.cgi?id=1433 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/1434] IA64 assembler generates different debug info
--- Additional Comments From wilson at specifix dot com 2005-10-07 01:19 --- Subject: Re: IA64 assembler generates different debug info On Thu, 2005-10-06 at 17:33, hjl at lucon dot org wrote: > -5e01 00020027 R_IA64_DIR64LSB .text + 12 > +5e01 00020027 R_IA64_DIR64LSB .text + 11 Isn't this exactly the same problem as gas/1433? Interpretation of tags in the presence of long instructions? -- http://sourceware.org/bugzilla/show_bug.cgi?id=1434 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/1433] IA64 assembler generates bad 2.6.9 Linux kernel.
--- Additional Comments From wilson at specifix dot com 2005-10-07 06:53 --- Subject: Re: IA64 assembler generates bad 2.6.9 Linux kernel. On Fri, 2005-10-07 at 04:32 +, hjl at lucon dot org wrote: > --- Additional Comments From hjl at lucon dot org 2005-10-07 04:32 > --- > Will this kernel change fix the kernel? Will this kernel change work with > the old assembler? The patch will work regardless of what slot the assembler uses for the tag, so yes it will work for both the old and new assemblers. I don't know if it will fix the kernel. You will have to try it. It looks like it will fix the one problem you identified. There could be other problems, though it seems unlikely. -- http://sourceware.org/bugzilla/show_bug.cgi?id=1433 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/1434] IA64 assembler generates different debug info
--- Additional Comments From wilson at specifix dot com 2005-10-07 06:56 --- Subject: Re: IA64 assembler generates different debug info On Fri, 2005-10-07 at 04:30 +, hjl at lucon dot org wrote: > --- Additional Comments From hjl at lucon dot org 2005-10-07 04:30 > --- > The difference is I don't think this alone will cause kernel boot problem. So there is no actual bug here apparently. You just noticed the debug info was different. In that case, the answer is yes it is different, and the difference is accidental, however, since the old debug info was technically wrong, I think we should keep the new behaviour. And yes, this is the same problem as PR 1433. -- http://sourceware.org/bugzilla/show_bug.cgi?id=1434 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/1889] as looping infinitely on maybe invalid input
--- Additional Comments From wilson at specifix dot com 2005-11-23 01:52
---
We only need two lines to trigger the bug.
.mmi
br.call.sptk.many b0 = splay_tree_new#
The insn doesn't fit in the template, and we end up going round and round never
making any forward progress. We have some code to handle this, but it was only
enabled for the manual_bundling case, i.e. the "{ .mmi br.call }" case. Fixing
this requires only enabling this code even when we aren't doing manual bundling.
--
What|Removed |Added
Status|NEW |ASSIGNED
http://sourceware.org/bugzilla/show_bug.cgi?id=1889
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/1889] as looping infinitely on maybe invalid input
--- Additional Comments From wilson at specifix dot com 2005-11-23 01:54 --- Try assigning it to myself again. -- What|Removed |Added AssignedTo|unassigned at sources dot |wilson at specifix dot com |redhat dot com | http://sourceware.org/bugzilla/show_bug.cgi?id=1889 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/1889] as looping infinitely on maybe invalid input
--- Additional Comments From wilson at specifix dot com 2005-11-23 02:01 --- Fix checked in to mainline. http://sourceware.org/ml/binutils/2005-11/msg00334.html -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://sourceware.org/bugzilla/show_bug.cgi?id=1889 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/994] section switch in function causes segfault
--- Additional Comments From wilson at specifix dot com 2005-11-23 03:25 --- I spent some time looking at this, and I'm giving up. I'm just making this a hard error. If someone else wants to try to make this work, good luck. There are a number of problems here. The .endp is ending up in the wrong frag, because we are in the wrong section. Switching back to the text section before the .endp doesn't help though, as there are other problems. We still have a break in the frag chain. The code in subsegs.c creates a list of frags, one for each text section. The code in tc-ia64.c assumes that all frags except the last one have been "fix"ed. However, with subsegs, we can have multiple un"fix"ed frags. Then there are larger problems such as how to manage code in multiple text sections given that the current assembler unwind support only knows how to handle one section at a time. Plus the fact that the compiler isn't emitting any sensible unwind info for the other text sections. The problems here are far beyond the scope of what I can do, other than just emit an error. -- What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://sourceware.org/bugzilla/show_bug.cgi?id=994 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/994] section switch in function causes segfault
--- Additional Comments From wilson at specifix dot com 2005-11-23 04:41 --- Fixed on mainline. http://sourceware.org/ml/binutils/2005-11/msg00335.html -- What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://sourceware.org/bugzilla/show_bug.cgi?id=994 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/1298] m68k-dis.c:1348: warning: argument 'info' might be clobbered by 'longjmp' or 'vfork'
--- Additional Comments From wilson at specifix dot com 2006-04-03 22:20 --- This is due to a gcc bug. Unfortunately, this bug may be hard to fix. Meanwhile, binutils will fail to compile if affected files are compiled with -Werror. Short term workarounds might be to rearrange the code to try to avoid the spurious warning, or compile affected files with -Wno-error. This bug is only known to appear on an ia64 host, because it requires a certain set of conditions that only exist with the IA-64 architecture. See GCC PR 21059. I have a long explanation of the problem and some possible workarounds in there. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21059 -- http://sourceware.org/bugzilla/show_bug.cgi?id=1298 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/2809] ld incorrect applies LTOFF22X/LDXMOV relocations
--- Additional Comments From wilson at specifix dot com 2006-06-23 21:02 --- Subject: Re: New: ld incorrect applies LTOFF22X/LDXMOV relocations On Mon, 2006-06-19 at 23:49, cgray at cse dot unsw dot edu dot au wrote: > ld on ia64 applies LTOFF22X and LDXMOV relocations at linktime, voilating the > ABI. If you read the documentation for LTOFF22X and LDXMOV, it clearly says that they are link time optimizations. So there is no ABI violation here. However, you do have a point. There is an internal consistency problem in the IA-64 ABI. There is one place where it says segments (not sections) can be arbitrarily remapped at load time, and there is another place where it says you can perform a link time optimization that requires that the relative mapping of gp addressable segments is preserved at load time. I see nothing that resolves this conflict. This is a bug in the IA-64 ABI that should be reported to the maintainers of the ABI. The LTOFF22X/LDXMOV stuff was added late, long after the original ABI was written. I suspect that the only people who ever thought that segment remapping at load time was a good idea was the Monterey project folks, and that project died a long time ago. So when people added the LTOFF22X optimization, they didn't realize that it conflicted with the old stuff that allowed arbitrary segment remapping. Unfortunately, the ABI may not be fixed in a way that helps you, since probably remapping of segments at load time will be restricted to ensure that the LTOFF22X reloc continues working. Meanwhile, it appears that you have the right to remap gp addressable data segments to different places with the current ABI. I would question the wisdom of doing this though. You risk gp overflows for large programs. You disable a link-time optimization, resulting in slower code. Either you fail to perform the optimization, or you have to do it every time the code is loaded instead of just once at link time. It seems an unwise choice unless you have an important reason for doing. But since you insist on doing it, we need to modify the linker to allow you do to this. However, there is no way that we are going to change the behaviour of linux here. We can add a configuration option for your OS, so that it can be enabled by default. This means we need a configure tuple for your OS, which will then work differently than all existing ia64 operating systems. Since you are writing the OS, you may need to do some of this work yourself. I don't have your target configure tuple, nor do I have a copy of your OS to test against, nor do I know any other details of your OS. What you will want to do here is add a new vector for your OS to bfd, and then modify the elfxx-ia64.c file, in the function elfNN_ia64_relax_section to check the vector, and disable the LTOFF22X and LDXMOV optimizations when this vector is true. See for instance how the ia64_hpux_big_vec stuff works. Just grep for that and write something very similar for your target. -- http://sourceware.org/bugzilla/show_bug.cgi?id=2809 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/2809] ld incorrect applies LTOFF22X/LDXMOV relocations
-- What|Removed |Added Status|NEW |ASSIGNED http://sourceware.org/bugzilla/show_bug.cgi?id=2809 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/2809] ld incorrect applies LTOFF22X/LDXMOV relocations
-- What|Removed |Added AssignedTo|unassigned at sources dot |wilson at specifix dot com |redhat dot com | http://sourceware.org/bugzilla/show_bug.cgi?id=2809 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/2809] ld incorrect applies LTOFF22X/LDXMOV relocations
--- Additional Comments From wilson at specifix dot com 2006-07-07 23:15 --- Not a binutils bug. Binutils needs to be ported to the new OS. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||WONTFIX http://sourceware.org/bugzilla/show_bug.cgi?id=2809 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/2869] IA64: relocation truncated to fit: TPREL22
--- Additional Comments From wilson at specifix dot com 2006-07-08 00:06 --- Subject: Re: IA64: relocation truncated to fit: TPREL22 On Thu, 2006-07-06 at 10:47, gary at intrepid dot com wrote: > Can the compiler determine that TPREL22 won't work, or might a new > compilation switch (ala, -fbig-tls) be needed? Try -mtls-size=64. HJ's example compiles fine with that option. -- http://sourceware.org/bugzilla/show_bug.cgi?id=2869 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/2895] Looking for gasp
--- Additional Comments From wilson at specifix dot com 2006-07-10 18:44 --- Subject: Re: New: Looking for gasp On Sun, 2006-07-09 at 13:05, steveo at syslang dot net wrote: > I used to use gasp (the gas macroprocessor) a long time ago and I have someone > who now needs it. By googling around I saw that it was folded into binutils > but > that it's now gone from there. gasp was deprecated in binutils-2.13 and removed in binutils-2.14. You are now supposed to use the macro directives recognized by gas directly, instead of via a preprocessor. See the gas documentation for .macro, .if, .else, etc. -- http://sourceware.org/bugzilla/show_bug.cgi?id=2895 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/3169] elfxx-ia64.c doesn't support @ltoff(@fptr(_DYNAMIC#))
--- Additional Comments From wilson at specifix dot com 2006-09-11 20:26 --- Subject: Re: New: ld elf64-ia64.c segfault in set_fptr_entry On Sun, 2006-09-03 at 10:36 +, tbm at cyrius dot com wrote: > It fails both with Debian binutils 2.17 and current CVS HEAD. > /gcc-lib/ia64-linux-gnu/3.3.6/../../../crti.o symbol.s.o > /usr/bin/ld: BFD 2.17 Debian GNU/Linux assertion fail elf64-ia64.c:4874 > Segmentation fault There is a bug in the source code. It has #pragma weak _DYNAMIC void _DYNAMIC(void); if ((&_DYNAMIC != __null) && (d = (Elf64_Dyn *) _DYNAMIC)) ...process d as if it points to dynamic entries... This won't work on IA-64, as taking the address of a function returns the address of the function pointer. You would then have to redirect through the function pointer to get the actual function address you want. But to do so would be pointless. It is better to declare _DYNAMIC properly in the first place. If you use this extern char _DYNAMIC[0]; then you won't get a linker segfault, and you will also get code that has a chance of working. The linker shouldn't be segfaulting of course though. The linker bug appears to be in allocate_fptr in bfd/el64-ia64.c. This function returns false in this case, as a bfd_elf_link_record_local_dynamic_symbol call fails. I didn't look into this routine in detail, but this failure seems OK, as we can't make _DYNAMIC a local symbol presumably. The failure return result from allocate_fptr gets lost though, as it is called from a hash table traversal routine that throws away return values. Thus no error is emitted here, and no fptr section space is allocated. When we eventually try to generate the descriptor, we get the segfault as we are writing as no space was ever allocated for it. So the solution here seems to be to either fix the elf64_ia64_dyn_sym_traverse function to return failure results, or else emit the error in allocate_fptr directly. The latter seems easier. My problem at the moment now is that I'm not quite sure what the error message should be. Is there such a thing as a global dynamic symbol? If so, maybe the error should be something like "can't resolve fptr reloc for global dynamic symbol" Or maybe something more general like "invalid fptr reloc" or "failed to allocate fptr reloc" is more appropriate. -- http://sourceware.org/bugzilla/show_bug.cgi?id=3169 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/3169] elfxx-ia64.c doesn't support @ltoff(@fptr(_DYNAMIC#))
--- Additional Comments From wilson at specifix dot com 2006-09-13 21:01
---
Subject: Re: elfxx-ia64.c doesn't support
@ltoff(@fptr(_DYNAMIC#))
On Mon, 2006-09-11 at 22:17 +, hjl at lucon dot org wrote:
> + (*_bfd_error_handler)
> + (_("%B: failed to record local dynamic symbol `%s'"),
> +h->root.u.def.section->owner, h->root.root.string);
That looks like a good solution for this problem.
> However, it doesn't work for this:
Yes, this is another complication. The problem here is that _DYNAMIC is
a magic linker variable. It isn't a variable that came from one of the
object files. The variable gets created by a call to
_bfd_elf_define_linkage_sym, which puts it in the global symbol hash
table, but not the symbol list for the bar.o file as it didn't come from
bar.o. However, it is in the bar.o .dynamic section which has a
section->owner which points to bar.o. So in allocate_fptr, we call
global_sym_index, which then assumes that it must be in bar.o, and
segfaults because it doesn't handle the failure case.
There are a few interesting things about your testcase. I get the same
error if I use _GLOBAL_OFFSET_TABLE_ instead of _DYNAMIC. I get no
error if I switch the order of the .o files on the link line. This is
because section->owner now points to foo.o, and the variable is in
foo.o's symbol table because it was explicitly referenced there.
I think we can handle this with a simple extension of your current
patch. First we fix global_sym_index to handle the failure case where p
== 0. We can just return 0 in that case. Second, we fix allocate_fptr
to check for a 0 return value from global_sym_index, and emit the same
error message as above.
I don't think there is any field in a symbol that says this is a magic
linker created variable. That would be convenient if it existed.
--
http://sourceware.org/bugzilla/show_bug.cgi?id=3169
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/3191] Dwarf 2 reader in linker doesn't suppor DW_FORM_ref_addr
--- Additional Comments From wilson at specifix dot com 2006-09-20 19:31 --- Subject: Re: Dwarf 2 reader in linker doesn't suppor DW_FORM_ref_addr On Wed, 2006-09-20 at 19:02 +, hjl at lucon dot org wrote: > When reporting linker error, dwarf2 reader doesn't support more than one > .debug_info section. You can only have more than one debug_info section when -feliminate-dwarf2-dups is used. This isn't a commonly used option, and there may be a number of problems with it. This is allowed by DWARF3, but not by DWARF2. I see how your patch might help now. The debug info is 32-bits as I mentioned earlier. The problem here is that pointers are 64-bits. read_address uses addr_size, and hence is reading a 64-bit address when it should be reading a 32-bit address, thus getting a number that is too large. Your fix adding 64-bit debug support helps because in the 32-bit case you replaced the read_address call with a read_4_bytes call, which correctly reads the 32-bit value we want. However, this is speculation, as I don't know how to reproduce the failure. I don't understand why this hasn't come up before. Also, it isn't clear what this has to do with the further information you have provided about multiple debug_info sections. -- http://sourceware.org/bugzilla/show_bug.cgi?id=3191 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/3276] Alignment error with static const variable in inline function
--- Additional Comments From wilson at specifix dot com 2006-09-28 21:30 --- Subject: Re: New: Alignment error with static const variable in inline function On Thu, 2006-09-28 at 07:42 +, jespdj at hotmail dot com wrote: > g++ outputs the correct assembler code, so the error must be in as or ld. Or, more likely, in the OS. Try running objdump -x on your executable. If the .rdata section has alignment 2**4, then the linker is OK. It is your OS (i.e. the loader) that isn't respecting the alignment. I tried this on an i386-cygwin system, and it looked OK to me. The rdata section has the right alignment, and the program worked. I didn't do this with binutils-2.17 though. I used the one I already had. -- http://sourceware.org/bugzilla/show_bug.cgi?id=3276 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/3990] [PATCH] IA64 gas DV: reports spurious WAW hazards
--- Additional Comments From wilson at specifix dot com 2007-03-27 01:23 --- This looks right to me. The bug is curious, but apparently we only handle or.andcm and and.orcm because these are the only parallel compares that gcc is smart enough to emit. So when we added support for these parallel compare types to gcc, we only extended gas to handle these, and forgot to handle the others at the same time. The code could maybe be a bit more efficient. We have 4 strstr calls, then a conditional expression with 4 ? tests. This isn't a reason to refuse it though. There is one important consideration here about copyright assignments. This was originally sent from an in.ibm.com address, and then from a freenet.de address. I need to be sure about who wrote the patch, and that they have a valid copyright assignment. If this was written by an IBM employee, then it presumably falls under the IBM corporate assignment. -- What|Removed |Added Status|NEW |ASSIGNED http://sourceware.org/bugzilla/show_bug.cgi?id=3990 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/4791] etc/standards.texi: @strong{Note...} produces a spurious cross-reference in Info
--- Additional Comments From wilson at specifix dot com 2007-08-01 17:57
---
Subject: Re: etc/standards.texi: @strong{Note...}
produces a spurious cross-reference in Info
On Wed, 2007-08-01 at 16:05 +, nightstrike at gmail dot com wrote:
> Proposed patch to change two lines in standards.texi
standards.texi is not a binutils file, it is an FSF documentation file.
It is wrong to change the wording of it without approval from the FSF.
A better solution is to import a new version from upstream, which
hopefully already has this fixed. If not, then we should be reporting
the bug upstream so they can fix it, and so we can then import a fixed
version.
See
http://www.gnu.org/prep/standards/
It looks like this problem has already been fixed upstream, though I
didn't look at this very closely.
--
http://sourceware.org/bugzilla/show_bug.cgi?id=4791
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/4791] etc/standards.texi: @strong{Note...} produces a spurious cross-reference in Info
--- Additional Comments From wilson at specifix dot com 2007-08-02 00:00
---
Subject: Re: etc/standards.texi: @strong{Note...}
produces a spurious cross-reference in Info
On Wed, 2007-08-01 at 23:10 +, nightstrike at gmail dot com wrote:
> I didn't realize there was the hierarchy you describe. Where is the cvs
> repository for the "upstream"?
The project page is here
http://savannah.gnu.org/projects/gnustandards
You can get to the cvs repository for this project from there, under
Development Tools.
--
http://sourceware.org/bugzilla/show_bug.cgi?id=4791
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
