This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: RFC: Access TLS symbols without DWARF debuginfo
- From: Daniel Jacobowitz <drow at false dot org>
- To: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Fri, 25 Aug 2006 09:43:16 -0400
- Subject: Re: RFC: Access TLS symbols without DWARF debuginfo
- References: <20060825021304.GA30225@host0.dyn.jankratochvil.net>
On Fri, Aug 25, 2006 at 04:13:04AM +0200, Jan Kratochvil wrote:
> Hi,
>
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=185337
>
> currently if you have threaded (-lpthread) program compiled without debuginfo
> "-g" and you try to access TLS symbol you will get:
> (gdb) print thread_local
> Cannot access memory at address 0x0
>
> as gdb tries to resolve TLS-offset as absolute memory reference.
>
> In fact it occurs if you try to access "errno" on -lpthread program with
> debuginfo lower than -ggdb3.
>
> Attached patch implements accessing them without the debuginfo suggestions as
> not always such associatet debuginfo is available. It checks for
> SYMBOL_BFD_SECTION (msymbol)->flags & SEC_THREAD_LOCAL
> symbols, implements for them new `UNOP_MEMVAL_TLS' and reuses for them former
> `dwarf_expr_tls_address'.
Thanks for doing this. It's a good idea, and the first step to not
needing libthread_db to do this - in most cases the gdbarch vector
should have enough knowledge. And overall the patch looks very nice.
The same general comments apply as to your other patch, e.g. about a
ChangeLog.
Could you explain why you added a new kind of value for this? I'd have
thought that when we wanted the address of the symbol, we should be
able to resolve it. So instead of value_at_lazy_tls, we would resolve
the address using the target. Expressions persist between threads and
executions, but values shouldn't. That should simplify the code a
little.
--
Daniel Jacobowitz
CodeSourcery