This is the mail archive of the
mailing list for the glibc project.
Re: dlmopen and core dumps
- From: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: "Carlos O'Donell" <carlos at systemhalted dot org>, Roland McGrath <roland at hack dot frob dot com>, libc-alpha at sourceware dot org, gbenson at redhat dot com
- Date: Thu, 3 Jan 2013 20:22:40 +0100
- Subject: Re: dlmopen and core dumps
- References: <20121213214047.4D5652C0BF@topped-with-meat.com><50CB55A5.email@example.com><CAE2sS1gnk0vCgWFpmxQVLfcNOGYU3SRXU-ZtpfBU4JFZoPo2tw@mail.gmail.com><50CB6100.firstname.lastname@example.org><CAE2sS1iRo8_Z1zCkGN==cU0b=-zy_4o1GpTxk02Rpq+QoFhVNw@mail.gmail.com><20121219180552.GA19512@host2.jankratochvil.net><50D20572.email@example.com><50E5CD5D.firstname.lastname@example.org><20130103183804.GA19398@host2.jankratochvil.net><50E5D447.email@example.com>
On Thu, 03 Jan 2013 19:56:07 +0100, Pedro Alves wrote:
> You'd have to consider also how to update that
> block around DSO loads/unloads, most specially unloads (due to the resulting hole).
Loads happen only to the end. During unload I was thinking that a hole should
be OK because no large unloads from non-last libraries ever happen I hope.
At least I guess, I do not know specifics of the case of thousands libraries
Google was presenting.
> It seems to me that having the loader manage this block if bound to
> penalizing/slowing normal operation over debugging. It may not be that simple.
I was just showing a complete data structure redesign may bring some benefits.