This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: Preserve PLT flag in copy_indirect
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: binutils at sources dot redhat dot com
- Date: Wed, 12 Nov 2003 13:24:06 -0500
- Subject: Re: Preserve PLT flag in copy_indirect
- References: <20030819020542.GA31092@nevyn.them.org>
On Mon, Aug 18, 2003 at 10:05:42PM -0400, Daniel Jacobowitz wrote:
> Without this patch, linking to a modified libgcc I'm working with yields
> (arm-linux):
>
> /opt/mvista/BUILD/binutils-2.14/objdir/ld/ld-new: warning: type and size of dynamic symbol `__divdf3@@GCC_3.0' are not defined
> /opt/mvista/BUILD/binutils-2.14/objdir/ld/ld-new: warning: type and size of dynamic symbol `__gedf2@@GCC_3.0' are not defined
> /opt/mvista/BUILD/binutils-2.14/objdir/ld/ld-new: warning: type and size of dynamic symbol `__negdf2@@GCC_3.0' are not defined
> /opt/mvista/BUILD/binutils-2.14/objdir/ld/ld-new: warning: type and size of dynamic symbol `__muldf3@@GCC_3.0' are not defined
> /opt/mvista/BUILD/binutils-2.14/objdir/ld/ld-new: warning: type and size of dynamic symbol `__adddf3@@GCC_3.0' are not defined
> /opt/mvista/BUILD/binutils-2.14/objdir/ld/ld-new: warning: type and size of dynamic symbol `__extendsfdf2@@GCC_3.0' are not defined
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x0806de70 in elf32_arm_relocate_section (output_bfd=0x80da408,
> info=0x80c6ec0, input_bfd=0x80f9360,
>
> The problem appears to be caused by some missing .type directives; they
> aren't STT_FUNCTION but they need PLT slots. This patch fixes it, but does
> not fix a similar problem for i386. Accidentally, I discovered that setting
> ELF_LINK_HASH_NEEDS_PLT on _all_ bfd_link_hash_indirect symbols fixes it
> (swapped an & and an |); so something isn't being tagged as needing a PLT
> slot that should be. The symptom is:
> 080495bc R_386_COPY Func
>
> i.e. a copy reloc where we should have a JUMP_SLOT reloc instead. Test case
> attached.
>
> Thoughts? Is the patch right, and what's still wrong on i386?
Alan, you said this patch was "possibly" right. I dropped it because
the only time it was causing me a problem was on dodgily untyped
functions. I just ran into it again on MIPS - losing the
ELF_LINK_HASH_NEEDS_PLT flag caused us to not emit a lazy-resolution
stub. So is this patch OK?
> 2003-08-18 Daniel Jacobowitz <drow@mvista.com>
>
> * elf.c (_bfd_elf_link_hash_copy_indirect): Preserve
> ELF_LINK_HASH_NEEDS_PLT.
>
> Index: elf.c
> ===================================================================
> RCS file: /cvs/src/src/bfd/elf.c,v
> retrieving revision 1.198
> diff -u -p -r1.198 elf.c
> --- elf.c 7 Aug 2003 08:38:07 -0000 1.198
> +++ elf.c 19 Aug 2003 01:59:25 -0000
> @@ -1361,6 +1361,10 @@ _bfd_elf_link_hash_copy_indirect (const
> | ELF_LINK_HASH_REF_REGULAR_NONWEAK
> | ELF_LINK_NON_GOT_REF));
>
> + /* Are there any other flags we should be preserving? */
> + dir->elf_link_hash_flags |= (ind->elf_link_hash_flags
> + & ELF_LINK_HASH_NEEDS_PLT);
> +
> if (ind->root.type != bfd_link_hash_indirect)
> return;
>
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer