This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Design goals of the dynamic loader.
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Siddhesh Poyarekar <siddhesh at redhat dot com>
- Cc: Roland McGrath <roland at hack dot frob dot com>, libc-alpha at sourceware dot org
- Date: Mon, 20 Jul 2015 10:19:05 -0400
- Subject: Re: Design goals of the dynamic loader.
- Authentication-results: sourceware.org; auth=none
- References: <1437033625-13561-1-git-send-email-siddhesh at redhat dot com> <55A7D4D6 dot 9030407 at redhat dot com> <20150717032846 dot GA19592 at spoyarek dot pnq dot redhat dot com> <55A87E63 dot 5030506 at redhat dot com> <20150717043706 dot GC19592 at spoyarek dot pnq dot redhat dot com> <55A931B0 dot 1010208 at redhat dot com> <20150718014326 dot GI19592 at spoyarek dot pnq dot redhat dot com> <20150718021516 dot 002BF2C2446 at topped-with-meat dot com> <20150718024952 dot GJ19592 at spoyarek dot pnq dot redhat dot com> <55ACEFE8 dot 2080409 at redhat dot com> <20150720135104 dot GB10318 at spoyarek dot pnq dot redhat dot com>
On 07/20/2015 09:51 AM, Siddhesh Poyarekar wrote:
> On Mon, Jul 20, 2015 at 08:56:08AM -0400, Carlos O'Donell wrote:
>> I agree completely, but we would need to replace it with something like
>> stap-based probe tracing which compiles to nop's normally but allows an
>> external program like systemtrace to be used to trace library loading with
>> all the same detailed data as before but for developers only (and ship
>> the stap script with libc.so.6).
>
> I don't understand - we already have stap probe points in ld.so that
> do this and we also have LD_DEBUG, which gives the ability to trace
> ld.so activities the conventional way, i.e. by dumping to a file or
> stderr. Neither have anything to do with ldd.
The latter two are code in the core loader that are more difficult
to audit than stap-based probes? If we removed all trace an debug code
from and moved to stap, we would have something that is even easier to audit?
Cheers,
Carlos.