This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc 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: PING^1: [PATCH 1/2] Mark ld.so internal mmap functions hidden in ld.so



On 06-01-2016 16:53, H.J. Lu wrote:
> On Wed, Jan 6, 2016 at 10:34 AM, Adhemerval Zanella
> <adhemerval.zanella@linaro.org> wrote:
>> Checking of the dissassemble ld.so for i686 I see no PLT stub
>> being generated for mmap or it being called through it:
>>
>> $ objdump -d elf/ld.so
>> [...]
>>     5cdc:       89 04 24                mov    %eax,(%esp)
>>     5cdf:       e8 fc 49 01 00          call   1a6e0 <__mmap>
>> [...]
>>
>> Also regarding mmap I see that generated assembly generated is
>> not different without the patch. I do see that for the part 02
>> of the patch for the __libc_{open,close} with the patch a
>> call to __x86.get_pc_thunk.bx is removed (which is the intention
>> of the patch).
>>
>> Am I missing something here?
>>
> 
> Since __mmap is local in /lib/ld-linux.so.2:
> 
>    329: 00019370    86 FUNC    LOCAL  DEFAULT   11 __mmap
> 
> linker won't use PLT.  But since we don't tell GCC about it,
> GCC will assume PLT is used:
> 
> 000052a5  00023e04 R_386_PLT32            00000000   __mmap
> 
> which reserves EBX for PLT.  With my patch, you will see
> 
> 000052a5  00023e04 R_386_PC32           00000000   __mmap
> 
> which frees EBX for other use.
> 

Right, I am not sure why in my environment I do no see any call to
__x86.get_pc_thunk.bx prior __mmap call for librtld.os.  However
I do see that R_386_PLT32 calls are being generated.

Patch LGTM.


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