Re: your mail

[Joe deBlaquiere <jadb@redhat.com>]

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 priority
> assigned).