This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Preserve PLT flag in copy_indirect


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]