This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Export stack_used as __stack_used
- From: Pedro Alves <palves at redhat dot com>
- To: Andreas Schwab <schwab at linux-m68k dot org>
- Cc: Florian Weimer <fweimer at redhat dot com>, Gary Benson <gbenson at redhat dot com>, libc-alpha at sourceware dot org
- Date: Sat, 18 Jun 2016 12:08:46 +0100
- Subject: Re: [PATCH] Export stack_used as __stack_used
- Authentication-results: sourceware.org; auth=none
- References: <20160613112351 dot GA655 at blade dot nx> <1466163476-10459-1-git-send-email-gbenson at redhat dot com> <f6867d8f-3532-1ac2-cc7f-e7bb6ea12202 at redhat dot com> <20160617195018 dot GA20374 at blade dot nx> <ce9c88a4-5709-707e-c598-d438198df85f at redhat dot com> <987ac43c-9883-a194-9860-58e13cbe54e9 at redhat dot com> <m2bn2zyoo7 dot fsf at linux-m68k dot org>
On 06/18/2016 07:52 AM, Andreas Schwab wrote:
> Pedro Alves <palves@redhat.com> writes:
>
>> I think that nptl_version is another symbol that can potentially
>> cause the same problem:
>>
>> nptl_db/structs.def:51:DB_SYMBOL (stack_used)
>> nptl_db/structs.def:52:DB_SYMBOL (__stack_user)
>> nptl_db/structs.def:53:DB_SYMBOL (nptl_version)
>> nptl_db/structs.def:56:DB_SYMBOL (__nptl_threads_events)
>
> I think that DB_SYMBOL should use aliases with a unique prefix instead
> of the variable names directly, and those aliases should be put in the
> dynamic symbol table so that lookup still works if libthread is
> stripped.
Agreed. Requiring not-stripped libpthread used to
be a constant source of trouble for integrators, enough that gdb has a
FAQ entry about it:
https://sourceware.org/gdb/wiki/FAQ#GDB_does_not_see_any_threads_besides_the_one_in_which_crash_occurred.3B_or_SIGTRAP_kills_my_program_when_I_set_a_breakpoint
We don't hear about this problem a lot anymore though, I believe because
gdb nowadays does not rely on libthread_db for so many things as it used to.
I seem to remember this having been proposed in the past, but there having
been pushback against putting these symbols in the dynamic symbol table,
because that increases the dynamic symbol table size just for debugging...
If this is no longer a concern, I'm all for it.
Thanks,
Pedro Alves