[Bug gas/1804] New: Wrong output for 64-bit difference of labels
The assembler output for the following label difference is incorrect: .dword L$FE0061-L$FB0061 The order of the two 32-bit words in the 64-bit output are interchanged. This doesn't happen in every label difference. It has something to do with label expressions since outputing the difference directly using a hex constant works correctly. As far as I can tell, this output is mainly done by generic code (cons). Will attach the full test file shortly. -- Summary: Wrong output for 64-bit difference of labels Product: binutils Version: 2.17 (HEAD) Status: NEW Severity: critical Priority: P2 Component: gas AssignedTo: unassigned at sources dot redhat dot com ReportedBy: danglin at gcc dot gnu dot org CC: bug-binutils at gnu dot org GCC build triplet: hppa64-hp-hpux11.11 GCC host triplet: hppa64-hp-hpux11.11 GCC target triplet: hppa64-hp-hpux11.11 http://sourceware.org/bugzilla/show_bug.cgi?id=1804 --- 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/1804] Wrong output for 64-bit difference of labels
--- Additional Comments From danglin at gcc dot gnu dot org 2005-11-04 16:14 --- Created an attachment (id=743) --> (http://sourceware.org/bugzilla/attachment.cgi?id=743&action=view) Assembler testcase. The original assembler output generated by GCC has been hacked a bit. The label xyzzy was added as a marker for the FDE that's being incorrectly assembled. -- http://sourceware.org/bugzilla/show_bug.cgi?id=1804 --- 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/1811] New: ELF linker loads member of archive for common symbol
Unlink COFF linker, ELF link loads member of archive when there is a definition for a common symbol. -- Summary: ELF linker loads member of archive for common symbol Product: binutils Version: 2.17 (HEAD) Status: NEW Severity: normal Priority: P2 Component: ld AssignedTo: unassigned at sources dot redhat dot com ReportedBy: hjl at lucon dot org CC: bug-binutils at gnu dot org GCC target triplet: i686-pc-linux-gnu http://sourceware.org/bugzilla/show_bug.cgi?id=1811 --- 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/1811] ELF linker loads member of archive for common symbol
--- Additional Comments From hjl at lucon dot org 2005-11-04 21:19 --- Created an attachment (id=744) --> (http://sourceware.org/bugzilla/attachment.cgi?id=744&action=view) A testcase I got [EMAIL PROTECTED] archive]$ make gcc-c -o x.o x.c gcc-c -o foo.o foo.c ar rv libfoo.a foo.o ar: creating libfoo.a a - foo.o ld -r -o bar.o x.o libfoo.a libfoo.a(foo.o):(.bss+0x4): multiple definition of `bar' x.o:(.bss+0x0): first defined here make: *** [bar.o] Error 1 rm foo.o -- http://sourceware.org/bugzilla/show_bug.cgi?id=1811 --- 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
Re: DW_AT_high_pc and DW_AT_low_pc zero in DWARF-2 debug info in obje ct file in 64bit world
On Fri, Nov 04, 2005 at 04:04:05PM +0100, Mlynarik Jan wrote: > Hello, > > We are using a cross compiler for 64 bit Linux on MIPS yosemite. When we > compile c sources with command: > > mips64-linux-gnu-gcc -c -gdwarf-2 -mabi=64 example2.c > > then the values of DW_AT_high_pc and DW_AT_low_pc atributes in dwarf2 info > are 0, what is surely wrong. > > If we use "mips64-linux-gnu-gcc -c -gdwarf-2 -mabi=32" then there are > reasonable values in these attributes. > > This is not a problem of the dwarfdump, because this values can be found > also by hand in the object files. I don't know why it works for 32-bit and not for 64-bit. Readelf output would be more useful for that question. However, in general you can not use dwarfdump or readelf to look at unrelocated object files, only linked ones. If you use readelf -r, you will see relocations associated with the dwarf sections, at the offsets of the "bad" DW_AT_high_pc fields. This is not a bug. -- Daniel Jacobowitz CodeSourcery, LLC ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: ld doesn't warn about undefined symbols
On Wed, Nov 02, 2005 at 06:01:03PM +0100, Jakub Jermar wrote: > ld (from binutils 2.16) on mipsel doesn't warn about > undefined symbols with elf32-little and binary output > formats (and possibly others). > > When the output format is elf32-tradlittlemips, undefined > symbols are reported as expected. > My project needs to use both binary and elf32-little > targets, so it is essential for me to know what is going on. No, you don't need to use either. I strongly recommend you always let the linker target a format that it knows about, and use objcopy to convert to any other formats you want to generate. > boot.bin: boot.o test.o > $(LD) $(LFLAGS) boot.o test.o -o $@ > OUTPUT_FORMAT(elf32-little) > /*OUTPUT_FORMAT(binary)*/ $(LD) $(LFLAGS) boot.o test.o -o [EMAIL PROTECTED] $(OBJCOPY) -O binary [EMAIL PROTECTED] $@ -- Daniel Jacobowitz CodeSourcery, LLC ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/1811] ELF linker loads member of archive for common symbol
--- Additional Comments From hjl at lucon dot org 2005-11-04 21:50 --- The change was introduced by http://sourceware.org/ml/binutils/1999-12/msg00057.html -- What|Removed |Added CC||nickc at redhat dot com http://sourceware.org/bugzilla/show_bug.cgi?id=1811 --- 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/1811] ELF linker loads member of archive for common symbol
--- Additional Comments From hjl at lucon dot org 2005-11-04 21:59 --- According to the comment, the change was made to follow Solaris and HPUX. -- http://sourceware.org/bugzilla/show_bug.cgi?id=1811 --- 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/1811] ELF linker loads member of archive for common symbol
--- Additional Comments From kean at armory dot com 2005-11-05 04:39 --- For the record, I will repost a private mail I had with H.J about this. = Ok I've spent a while staring at that code and thinking about this, and even though you say it is there on purpose, I believe it is wrong. Here's why. It is expected behaviour to be able to over-ride variables and objects that appear in libraries, whether shared or archive makes no difference. For example, libraries like dmalloc depend on that behaviour. In this case, so do a lot of GNU programs. Even though libc may provide getopt, the program wants to provide its own getopt, especially for long option handling. An explicitly named object should always take precedence over an object in a library. The only reason that is *not* happening here is becuase GNU getopt declares optarg as: char *optarg; thus making it a common symbol. If I was to change that to char *optarg = 0; then it becomes a normal data symbol and it will be used in preference to the one in the library, which is exactly the intended behaviour. The only reason the link editor has to pull in teh object from the archive is if it provides some *other* symbol that the program needs, and in that case you would legitimately get a warning that the same symbol is defined in two places. However, simply rejecting the explicitly named object in favour of the object in the archive just becuase the explicit object didn't initialize the variable breaks a very fundamental UNIX paradigm. I read the mail thread pointed to in #2, and Ian asked what SVR4/UnixWare do. UnixWare treats it as I describe above. In fact the current GNU ld is broken on that platform because of this. I spoke to the author of the gABI and he maintains the Solaris linker is broken, and the UnixWare one is correct. With no prompting he cited almost the exact same reasons I outlined above. The problem is the gABI doesnt specify semantic interprtation of COMMON symbols. In the gABI authors words, that was because the behaviour was "older than ELF itself" and simply the way archives were meant to be handled. -- http://sourceware.org/bugzilla/show_bug.cgi?id=1811 --- 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/1811] ELF linker loads member of archive for common symbol
--- Additional Comments From ian at airs dot com 2005-11-05 05:07 --- Unfortunately it's too simple to allude to the historical handling of common symbols. In a.out linkers when a common symbol appears in an object, and the symbol is defined in an object in an archive, then the object in the archive is pulled into the link (actually this is somewhat target dependent--the SunOS linker would pull in definitions which were in the .data section but not ones which were in the .text sectin, assuming that a function could never merge with a common symbol). Moreover, if a common symbol appears in an object, and the symbol is a common symbol in an object in an archive, then in an a.out linker the size of the common symbol is changed, but the object is *not* pulled into the link. This last behaviour is of course pretty crazy. But in general it isn't reasonable for the ELF ABI to claim that they just rely on historical behaviour for the definition of common symbols, because in fact ELF common symbols do not act like historical ones do. That said, I was never all that happy with this change, and I think the behaviour before the change was more coherent. But, unfortunately, given the way that system files and libraries are written, it is important that we be compatible with system linkers. You say the UnixWare linker acts differently. That suggests that we need to make this target dependent. This is precedent for this in the a.out linker, and the use of the common_skip_ar_aymbols field in struct bfd_link_info. -- http://sourceware.org/bugzilla/show_bug.cgi?id=1811 --- 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
