This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Export stack_used as __stack_used


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]