This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] elf/dl-load.c: Remove local_strdup.
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Roland McGrath <roland at hack dot frob dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Fri, 24 Oct 2014 19:17:03 -0400
- Subject: Re: [PATCH] elf/dl-load.c: Remove local_strdup.
- Authentication-results: sourceware.org; auth=none
- References: <5449C26B dot 4070600 at redhat dot com> <20141024170123 dot 1F89B2C3ADA at topped-with-meat dot com> <544AB7D1 dot 9060809 at redhat dot com> <20141024214045 dot 53D4E2C3AB6 at topped-with-meat dot com>
On 10/24/2014 05:40 PM, Roland McGrath wrote:
>> I see that __strsep in dl-load.c is called with double underscore,
>> but why not strlen? Is it because for these routines, which are
>> always in ld.so, we rely on the ld.so copies of them?
>
> strlen is part of the most restricted name space (C89). strsep and strdup
> are not. Remember that this code can also be linked statically (it's part
> of libc.a). In ld.so proper, it doesn't matter concretely because it does
> not export these symbols and so will always use its own copies.
Thanks it's the static case I had forgotten to take into account.
>> I also thought for a second that a strcpy that went into the PLT
>> would trigger check-localplt failures, but then I saw ld.so is not
>> part of that test? Any reason why not?
>
> It's a surprise to me too, and I had to check to convince myself it really
> wasn't tested somehow. I don't see any reason it shouldn't be per se. Add
> it to the list and verify nothing goes wrong. But there are reasons it's
> far less likely ever to be a problem. ld.so has no dependencies and is
> built with -z defs, so it can never have undefined references and can never
> have PLT entries for anything but its own exported symbols (unless the
> linker grows new bugs). There is a very small set of exported symbols
> (elf/Versions) that almost never changes.
I'll do that now and commit as obvious. I can't see anyone objecting to
me touching arch localplt.data files.
Cheers,
Carlos.