This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: dlmopen and core dumps
- From: Paul Pluzhnikov <ppluzhnikov at google dot com>
- To: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- Cc: "Carlos O'Donell" <carlos at systemhalted dot org>, Pedro Alves <palves at redhat dot com>, Roland McGrath <roland at hack dot frob dot com>, libc-alpha at sourceware dot org, gbenson at redhat dot com
- Date: Wed, 2 Jan 2013 11:39:22 -0800
- Subject: Re: dlmopen and core dumps
- References: <20121105132108.GA4305@redhat.com> <CAE2sS1j8pNMhgunxNHvCofR-TuiJYk9HVTWk5OYz0MQN2_GuDg@mail.gmail.com><20121213214047.4D5652C0BF@topped-with-meat.com> <50CB55A5.2020007@redhat.com><CAE2sS1gnk0vCgWFpmxQVLfcNOGYU3SRXU-ZtpfBU4JFZoPo2tw@mail.gmail.com><50CB6100.7070100@redhat.com> <CAE2sS1iRo8_Z1zCkGN==cU0b=-zy_4o1GpTxk02Rpq+QoFhVNw@mail.gmail.com><20121219180552.GA19512@host2.jankratochvil.net>
Some notes from the trenches.
On Wed, Dec 19, 2012 at 10:05 AM, Jan Kratochvil
<jan.kratochvil@redhat.com> wrote:
> On Sat, 15 Dec 2012 01:20:03 +0100, Carlos O'Donell wrote:
>> Why not just run a generic program, or rather a python script?
>
> Python is needlessly expensive.
In addition, we've been using embedded Python scripts to support debugging
here, and have found keeping code and python scripts in sync to be a bit
of a challenge.
Writing an automated GDB test that verifies the "sync" state is possible;
requiring a working GDB every time you perform a "make check" in glibc is
not really plausible, especially when bootstrapping on a new platform.
> There does not exist only GDB, there exist
> other smaller tools examining external programs which can for example run on
> embedded targets.
And don't forget self-inspecting programs. When running on a cluster, it is
really handy for SIGSEGV and SIGABRT handler to be able to log symbolized
stack trace, which requires access to the list of loaded libraries [1].
> Why not to use DWARF expression code?
Sounds like an excellent idea to me.
[1] The list can be obtained by parsing /proc/self/maps, except /proc may
not be mounted, or may not be present in the chroot jail, or may be made
inaccessible by sandboxing policy.
--
Paul Pluzhnikov