This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB 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] |
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |