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 > /homes/local/mips-cross/crossdev-build/src/binutils-001027/bfd/elf32-mips.c > 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. Ralf
