RFC: Access TLS symbols without DWARF debuginfo v2

[Jan Kratochvil <jan dot kratochvil at redhat dot com>]

Hi,

attached a single unifying/dropping patch those 3 patches before.


2006-08-25  Jan Kratochvil  <jan.kratochvil@redhat.com>

	* dwarf2loc.c (dwarf_expr_tls_address): Code moved out to
	`target_translate_tls_address'.
	* target.c (target_translate_tls_address): Moved here.
	Provided warnings for TLS `errno' on non-TLS targets.
	* target.h (target_translate_tls_address): Moved here.
	* eval.c (evaluate_subexp_standard): New `UNOP_MEMVAL_TLS'.
	* expprint.c (print_subexp_standard): New `UNOP_MEMVAL_TLS'.
	(op_name_standard): New `UNOP_MEMVAL_TLS'.
	(dump_subexp_body_standard): New `UNOP_MEMVAL_TLS'.
	* expression.h (enum exp_opcode): New `UNOP_MEMVAL_TLS'.
	(union exp_element): New `objfile' type.
	* parse.c (write_exp_elt_objfile): New `objfile' setter.
	(write_exp_msymbol): Support new `UNOP_MEMVAL_TLS'.
	(msym_text_tls_symbol_type, msym_data_tls_symbol_type,
	msym_unknown_tls_symbol_type, build_parse): New TLS types.
	(operator_length_standard): New `UNOP_MEMVAL_TLS'.
	* parser-defs.h (write_exp_elt_objfile): New `objfile' setter.
	* valops.c (value_at_lazy): Pass control to `value_at_lazy_tls'.
	(value_at_lazy_tls): Provide TLS `struct objfile *' storage.
	(value_fetch_lazy): Resolve TLS `struct objfile *' storage.
	(value_assign): Resolve TLS `struct objfile *' storage.
	* value.c (struct value, allocate_value, value_tls_objfile,
	set_value_tls_objfile): Provide TLS `struct objfile *' storage.
	* value.h (value_tls_objfile, set_value_tls_objfile,
	value_at_lazy_tls): Provide TLS `struct objfile *' storage.
	* Makefile.in: Updated dependencies.

2006-08-25  Jan Kratochvil  <jan.kratochvil@redhat.com>

	* gdb.threads/tls-nodebug.c: New file, test TLS symbols on gcc -s.
	* gdb.threads/tls-nodebug.exp: New file, test TLS symbols on gcc -s.


On Fri, 25 Aug 2006 05:43:01 +0200, Daniel Jacobowitz wrote:
> First a general note: please include changelogs with patches.

Forgot again, last time, sorry.  Isn't there some tool to generate this
changelog type templates from the diff?


> Also in the minor feedback area, updates to included files need to be
> reflected in Makefile.in, and URLs to Red Hat's bugzilla are not appropriate
> for the FSF GDB; if you want to describe the problem, just do so.

Thanks for info, to be followed.
Personal info: That gnatsweb is just unusable, move to Bugzilla, please.


> On Fri, Aug 25, 2006 at 04:13:11AM +0200, Jan Kratochvil wrote:
> > * with -ggdb2 and less "errno" in fact does not exist anywhere as it was
> >   compiled to "(*__errno_location ())" and the macro definition is not present.
> >   Unfortunately gdb will find the TLS symbol and it will try to access it but
> >   as the program has been compiled without -lpthread the TLS base register
> >   (%gs on i386) is not setup and it will result in:
> >   	Cannot access memory at address 0x8
> 
> That can't be correct.  Every program using glibc references errno.
> If the program can access it, then GDB ought to be able to also.
> In this case, libc.so.6 exports a dynamic TLS symbol named errno.

If I compile code with or without -pthread (on Fedora Core 5) "errno" is never
found in the target (dynamic) executable.  "errno" is there only with -ggdb3 as:
	DW_MACINFO_define - lineno : 47 macro : errno (*__errno_location ())

Unaware why %gs is not being used in the user code.
%gs-using "errno.h" is available only during glibc compilation.  I get only:

8048915:       e8 1e fc ff ff          call   8048538 <__errno_location@plt>
804891a:       8b 00                   mov    (%eax),%eax
804891c:       89 04 24                mov    %eax,(%esp)


> Did you try this with the patch you posted earlier to access TLS
> without debug info?

Both patches were developed together.  Still that
	RFC: Ignore TLS symbols for non-TLS programs
		gdb-6.5-bz185337-missing-errno-suggestion.patch
had been mostly obsolete by the other one and deprecated after your comments.


> > +++ gdb/minsyms.c	25 Aug 2006 01:42:27 -0000
...
> > +#include "target.h"
> 
> This violates the abstraction layers.  We're reading the symbols from
> a file.  Why should it matter what target we're connected to?  In fact,
> we probably aren't connected to a target yet.  Decisions about what we
> can access should only be made when we want to access it.

You are right, rewritten by your advice.  I had a problem delaying it before as
the TLS `errno' for non-TLS inferior detection had to be written differently.

The trailing part of `target_translate_tls_address' now already contains
	gdb-6.5-bz185337-missing-errno-suggestion.patch


> > +/* Test accessing TLS based variable without -lpthread / TLS setup.  */
> > +
> > +#include <pthread.h>
> > +
> > +__thread int thread_local = 42;
> > +
> > +int main(void)
> > +{
> > +  return 0;
> > +}
> 
> It would be legal for main to return the value of thread_local, even
> though it is not linked to pthread.c.

Sorry but I do not understand a reason to do so.


> Oh, and you don't actually need <pthread.h> for this.

Removed.

> > +if {[gdb_compile "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable []] != "" } {
> 
> Did you try this?  [] should give you a TCL syntax error.

It works, empty command produces empty string.
gdb-unified by '$options', though - thanks.


On Fri, 25 Aug 2006 15:43:16 +0200, Daniel Jacobowitz wrote:
> On Fri, Aug 25, 2006 at 04:13:04AM +0200, Jan Kratochvil wrote:
...
> > 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'.
...
> 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.

Sorry, I probably do not have such high overview of the code - what code would
you patch to "resolve the address using the target"?

The following text is probably useless:

% I just did not see there any target-specific code needing to be modified
% as former `dwarf_expr_tls_address' covers it nice.
% 
% I am aware the TLS-resolving should be done as late as possible as
% linux-thread-db.c providing its target_get_thread_local_address_p () may be
% initialized very late.
% 
% The latest possible time is `value_at_lazy_tls' but there is no longer
% available `struct objfile *' for `target_translate_tls_address'.
% So I had to pass such information somehow to `value_at_lazy_tls'.
% 
% The target info is `struct objfile *' for `target_translate_tls_address'.
% The source info is `bfd *' in `write_exp_msymbol'.
% I could store `bfd *' (`SYMBOL_BFD_SECTION (msymbol)->owner')
% or `int' (`SYMBOL_BFD_SECTION (msymbol)->owner->id')
% or `struct objfile *' (resolved from `bfd *').
% 
% I chose `struct objfile *', so I had to extend `struct value' to store it.
% I would have to extend `struct value' by some field anyway.
% I also had to extend `union exp_element' to store the new type there.
% I would have to extend `union exp_element' even for `bfd *',
% only in the case of chosen `bfd.id' `union exp_element' could be reused.
% 
% I do not find much difference how to store this additional information,
% I just did not find a way how to deal without it.


On Fri, 25 Aug 2006 15:47:50 +0200, Daniel Jacobowitz wrote:
> On Thu, Aug 24, 2006 at 11:43:01PM -0400, Daniel Jacobowitz wrote:
> > On Fri, Aug 25, 2006 at 04:13:11AM +0200, Jan Kratochvil wrote:
> > > * with -ggdb2 and less "errno" in fact does not exist anywhere as it was
> > >   compiled to "(*__errno_location ())" and the macro definition is not present.
> > >   Unfortunately gdb will find the TLS symbol and it will try to access it but
> > >   as the program has been compiled without -lpthread the TLS base register
> > >   (%gs on i386) is not setup and it will result in:
> > >   	Cannot access memory at address 0x8
> > 
> > That can't be correct.  Every program using glibc references errno.
> > If the program can access it, then GDB ought to be able to also.
> > In this case, libc.so.6 exports a dynamic TLS symbol named errno.
> > 
> > Did you try this with the patch you posted earlier to access TLS
> > without debug info?
> 
> Oh, I see now - that's not enough, you'd also need to implement direct
> DTV lookup in GDB since libthread_db probably can't cope.  And that
> might require some fiddling with e.g. the remote protocol, too, to get
> at the result of ps_get_thread_area.  Anyway, this is doable, just
> a bit of work.
> 
> With your other patch, I hope this would get a more appropriate error,
> like "can't access thread local data"?

I hope this is no longer to be resolved as this patch got dropped.
Sorry but I do not understand `DTV'.



Regads,
Jan

Attachment: gdb-6.5-bz185337-resolve-tls-without-debuginfo-v2.patch
Description: Text document