On Wed, Jan 03, 2001 at 05:36:44PM -0800, John Van Horne wrote:
> First, while the kernel builds just fine, when we use objcopy to convert the
> elf image into a binary
> image which we can download to our target, objcopy fails with warnings
> saying that it is writing
> sections to huge (i.e. negative) file offsets. When I use objdump to analyze
> the kernel image,
> 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.
> Second, the way we build our application, we first create a partially linked
> image, with the -r flag. Then
> we run ld on this (and an additional object file). When we do this with the
> tools from cross-all-001027
> we get the following error on the second link step:
> mips-linux-ld: BFD internal error, aborting at
> line 6942 in _bfd_mips_elf_relocate_section
> mips-linux-ld: Please report this bug.
Not good ... Two possibilities.
- it's fairly easy to make ld die in funny ways by feeding it with nonsense
options, linker scripts or similar.
- it's really a bug.
Assuming it's really a bug, can you extract a small test case that
demonstrate this bug?
> Actually, on the application we didn't get this far using
> binutils-mips-linux-2.8.1 and egcs-mips-linux-1.0.3a,
> so I have nothing to compare it to. I'm not sure if this is a bug or if I
> should be passing some flags to gcc or ld.
It may well be a bug; especially -r is used relativly rarely so the code
isn't getting excercised too well. I'd like to see it get fixed in the
current linker, though.