This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: Objcopy fix for relocation sections
- From: Daniel Jacobowitz <drow at false dot org>
- To: binutils at sources dot redhat dot com, James Troup <james at nocrew dot org>
- Date: Thu, 5 Aug 2004 09:14:30 -0400
- Subject: Re: Objcopy fix for relocation sections
- References: <20031222210543.GA3418@nevyn.them.org> <20031223032137.GD1618@bubble.sa.bigpond.net.au> <20040727210426.GA11595@nevyn.them.org> <20040803225601.GA22637@nevyn.them.org> <20040805092703.GF12879@bubble.modra.org>
On Thu, Aug 05, 2004 at 06:57:04PM +0930, Alan Modra wrote:
> On Tue, Aug 03, 2004 at 06:56:01PM -0400, Daniel Jacobowitz wrote:
> > * elf.c (assign_file_positions_except_relocs): Revert unintended
> > change from 2004-04-08.
>
> Oops, please fix.
>
> > (_bfd_elf_set_section_contents): Call
> > _bfd_elf_assign_file_positions_for_relocs when starting output
> > for executables and shared libraries.
>
> Doesn't this break mips? For example, I see an assignment to
> rel_hdr->sh_size in mips_elf64_write_rel. That size should determine
> section placement, but you're doing the placement before
> mips_elf64_write_rel is called.
Sparc64 does the same thing. The problem looks plausible. But I can't
reproduce it; I can't get the linker to pass MIPS combined relocations
through to a dynamic or executable module. If I try to fake it using
-q, some code that specifically takes care of the MIPS ugliness falls
over in elflink.h (now in elflink.c, I'm looking at an older
toolchain): in elf_bfd_final_link, esdi->rel_hdr.sh_entsize == 0.
So I have no way to check ;-)
If you're right, then I would like to go back to my first patch, the
one which places each reloc section as _bfd_elf_set_section_contents
is called on it. That will change the behavior of objdump without
changing the behavior of the assembler or linker.
--
Daniel Jacobowitz