|To:||"Maciej W. Rozycki" <email@example.com>|
|Subject:||Re: your mail|
|From:||Joe deBlaquiere <firstname.lastname@example.org>|
|Date:||Thu, 04 Jan 2001 10:40:41 -0600|
|Cc:||Ralf Baechle <email@example.com>, John Van Horne <JohnVan.Horne@cosinecom.com>, "'firstname.lastname@example.org'" <email@example.com>, "'firstname.lastname@example.org'" <email@example.com>|
|Organization:||Red Hat, Inc.|
|User-agent:||Mozilla/5.0 (X11; U; Linux 2.2.16-22 i686; en-US; m18) Gecko/20001107 Netscape6/6.0|
If the BFD stuff is built with any support for 64 bit (even as an
optional target) it will maintain all addresses as 64-bit values, even
if the file is 32 bit.
There is a bug in that "some" newer versions of objcopy will not allow you to translate these sign-extended 32 bit addresses into Intel Hex format.
If you're really only doing 32-bit mips you might consider removing the 64 bit targets in the config.bfd... I think that will solve the problems.
Maciej W. Rozycki wrote:
On Thu, 4 Jan 2001, Ralf Baechle wrote:I see that our start address of 0x80102584 has been turned into 0xffffffff80102584. I'm thinking that I need to tell ld something to stop it from doing this. Any ideas?That's be ok. 32-bit MIPS addresses are sign-extended into 64-bit addresses. Older binutils used to zero-extend addresses which was broken. So what you observe is actually the sympthom of a bug that got fixed.I'm not sure that's the best solution, I'm afraid. For elf32-mips addresses should be 32-bit and not 64-bit. It would be consistent with other 32-bit platforms, it would make interoperability easier (ksymoops cannot make use of System.map to grok kernel oopses which provide 32-bit addresses) and it would make objdump outputs more readable. Fixing this problem with BFD is on my to do list (but has a low priorityassigned).
|<Prev in Thread]||Current Thread||[Next in Thread>|