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: mips4/32-el BFD breakage


Daniel, et al,

OK, here are the diffs and the test application.

1. diff0 is for the shared library itself (libhello.so). I've
   stripped all differences for 40000 symbols. They are pretty much
   the same (offsets differ by 16)

2. diff1 is for the application (a.out)

Will get back to this problem tomorrow,

Pjotr Kourzanov
   
>On Mon, Mar 07, 2005 at 11:30:06AM -0500, Daniel Jacobowitz wrote:
>> Your patch is definitely incorrect.  If the indirect symbol needs a PLT
>> entry, then the defined symbol will need a PLT entry also.
>
>  Most likely, I was also quite surprised that it fixed anything.
>However, it really does fix it. That change made on 2003-11-17 really
>makes the difference (2003.11.18.05.37.00-2003.11.17.05.37.00),
>for binutils-2.14.90. I checked the code in binutils-2.15 and HEAD,
>they both seem to do the same thing, albeit in another way. And
>the patch actually improves both branches...
>
>  However, I know the problem is elsewhere, that's the reason I
>posted it here;-)
>
>> 
>> You've attached a patch against HEAD; however, did you verify that the
>> actual problem occured on HEAD?  Some multi-GOT bugs have been fixed
>
>  The HEAD code that I used was from about a week ago. I just checked
>the BFD version 2.15.95 20050307 from the HEAD and it fails on the 
>target with:
>
>-bash-3.00# ./a.out 
>Call functions in big shared library
>Segmentation fault
>-bash-3.00# 
>
>  The same versions compiled without need_plt work correctly:
>
>-bash-3.00# ./a.out 
>Call functions in big shared library
>Calling hello_0...hello_0
>Calling hello_999...hello_999
>Calling hello_39999...hello_39999
>-bash-3.00#
>
>> since binutils 2.15.  Also, can you explain why you made this
>> particular change and what affect it had on your binary?
>
>  Well, I guess the reason is to get large applications working 
>without having to resort to static linkage.
>
>  The huge shared library is slightly larger without the fix (this
>is to be expected, since some symbols are not copied). I am now 
>running objdump on both of them. Stay tuned...
>
>> 
>> -- 
>> Daniel Jacobowitz
>> CodeSourcery, LLC
>> 
>
>Pjotr Kourzanov

Attachment: shlib-hello-test.tgz
Description: GNU Unix tar archive

Attachment: diff0
Description: Text document

Attachment: diff1
Description: Text document


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