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: Florian Weimer <fweimer at redhat dot com>, Gary Benson <gbenson at redhat dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Fri, 17 Jun 2016 23:01:33 +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> <20160617201743 dot GA21074 at blade dot nx> <f77498e1-1465-68a0-ecbb-6d4e5b56cf2f at redhat dot com>
On 06/17/2016 09:31 PM, Florian Weimer wrote:
> On 06/17/2016 10:17 PM, Gary Benson wrote:
>> Gary Benson wrote:
>>> Florian Weimer wrote:
>>>> On 06/17/2016 01:37 PM, Gary Benson wrote:
>>>>> This commit renames "stack_used" as "__stack_used" and changes it
>>>>> from a static variable in allocatestack.c to an internally
>>>>> exported symbol available to all nptl source files. This fixes
>>>>> bug 17629 (and thus GDB PR 9635).
>>>>
>>>> What do you mean by âexportâ? The __ prefix suggests that you want
>>>> to export it as a symbol (probably GLIBC_PRIVATE), but I think you'd
>>>> need to update nptl/Versions in this case.
>>>
>>> No, I don't need that, it needs to be visible outside allocatestack.c
>>> but it doesn't need to be visible in, e.g., the output of "objdump -T".
>>>
>>>> If the variable remains nptl-internal, I expect that you could turn
>>>> it into a hidden symbol, and keep its current name.
>>>
>>> I may be wrong but I think its the rename that fixes the GDB bug.
Yes it is.
Should be trivial to reproduce. Simply write a test program that has
a global named "stack_used". The program is totally free to do that,
because that is a symbol name not in the implementation namespace.
See:
https://sourceware.org/bugzilla/show_bug.cgi?id=9635
And the small reproducer:
https://sourceware.org/bugzilla/attachment.cgi?id=5756
>>>
>>> If it's visible outside of allocatestack.c (i.e. it's not "static")
>>> then it should be named with a double-underscore, no?
>>
>> Oh, hang on, libthread_db looks it up _by_name_. How is that working
>> currently?
>
> It seems that libpthread_db calls ps_pglobal_lookup, which is provided
> by the âapplicationâ (so GDB).
Right. libthread_db.so is loaded as a plugin inside gdb's address
space. That library knows the layouts of the target's libpthread's
internals, but doesn't know where the addresses of the inferior's globals
are. So when libthread_db.so needs to know the address of
the target inferior's libpthread's "stack_used" symbol, it asks gdb,
via the proc-service interface.
The problem is that if the program being debugged defines its own
unrelated "stack_used" symbol, gdb can well return the address of
that unrelated global to libthread_db.so.
My initial attempt was to try to fix this in gdb, by restricting gdb's global
lookup to symbols defined in libpthread.so. However, it turned out that
that doesn't work when the inferior being debugged has been statically
linked, because in that case, libpthread is really linked inside
the main program, and thus there's no separate "libpthread.so" gdb can
restrict the symbol lookup in. So we're back to the same problem.
The solution I suggested in the PR then, is to rename the libpthread's
"stack_used" symbol, giving it a name that is in the implementation namespace.
I think it'd be reasonable if libthread_db's DB_GET_SYMBOL macro
had an assert that ensured that only symbols in the implementation
name space are looked up, even.
(Note that most of the libpthread symbols that libthread_db looks up
are prefixed "__nptl_"; such a prefix makes it even less likely to trip
on a conflict -- there's a remote but non-zero change that libgcc or
some other library part of the implementation has another symbol
named "__stack_used".)
> The mechanism is a bit weird: it almost
> looks as if someone thought about caching the name-based lookups in an
> array (with an index known at compile-time), but then never wrote the
> code to use a cache.
>
> We check that the symbols can be found in the .symtab section (so via
> debugging information, I assume, not .dynsym).
Here I'm afraid you lost me.
Thanks,
Pedro Alves