* Re: [PING][PATCH PR gdb/18071] TLS variables can't be resolved on aarch64-linux-gnu [not found] <1509636764-46111-1-git-send-email-weimin.pan@oracle.com> @ 2017-11-16 1:53 ` Wei-min Pan 2018-01-16 17:12 ` Yao Qi [not found] ` <515b875f-8240-b7e0-f5cc-4a26efb64b89@oracle.com> 1 sibling, 1 reply; 12+ messages in thread From: Wei-min Pan @ 2017-11-16 1:53 UTC (permalink / raw) To: gdb-patches On 11/2/2017 8:32 AM, Weimin Pan wrote: > Running the test case with upstream gdb shows two failures: > > (1) Receiving different error messages when printing TLS variable before > program runs - because the ARM compiler does not emit dwarf attribute > DW_AT_location for TLS, the result is expected and the baseline may > need to be changed for aarch64. > > (2) Using "info address" command on C++ static TLS object resulted in > "symbol unresolved" error - below is a snippet from the test case: > > class K { > public: > static __thread int another_thread_local; > }; > > __thread int K::another_thread_local; > > (gdb) info address K::another_thread_local > Symbol "K::another_thread_local" is unresolved. > > This patch contains fix for (2). > > Function info_address_command() handles the "info address" command and > calls lookup_minimal_symbol_and_objfile() to find sym's symbol entry in > mininal symbol table if SYMBOL_COMPUTED_OPS (sym) is false. Problem is > that function lookup_minimal_symbol_and_objfile() only looked up an > objfile's minsym ordinary hash table, not its demangled hash table, which > was the reason why the C++ name was not found. > > The fix is to call lookup_minimal_symbol(), which already looks up entries > in both minsym's hash tables, to find names when traversing the object file > list in lookup_minimal_symbol_and_objfile(). > > Tested in both aarch64-linux-gnu and amd64-linux-gnu. No regressions. > --- > gdb/ChangeLog | 5 +++++ > gdb/minsyms.c | 17 +++-------------- > 2 files changed, 8 insertions(+), 14 deletions(-) > > diff --git a/gdb/ChangeLog b/gdb/ChangeLog > index 4b292e0..2f630bc 100644 > --- a/gdb/ChangeLog > +++ b/gdb/ChangeLog > @@ -1,3 +1,8 @@ > +2017-11-01 Weimin Pan <weimin.pan@oracle.com> > + > + * minsyms.c (lookup_minimal_symbol_and_objfile): Use > + lookup_minimal_symbol() to find symbol entry. > + > 2017-10-27 Keith Seitz <keiths@redhat.com> > > * breakpoint.c (print_breakpoint_location): Use the symbol saved > diff --git a/gdb/minsyms.c b/gdb/minsyms.c > index 37edbd8..4edd8b1 100644 > --- a/gdb/minsyms.c > +++ b/gdb/minsyms.c > @@ -881,23 +881,12 @@ lookup_minimal_symbol_and_objfile (const char *name) > { > struct bound_minimal_symbol result; > struct objfile *objfile; > - unsigned int hash = msymbol_hash (name) % MINIMAL_SYMBOL_HASH_SIZE; > > ALL_OBJFILES (objfile) > { > - struct minimal_symbol *msym; > - > - for (msym = objfile->per_bfd->msymbol_hash[hash]; > - msym != NULL; > - msym = msym->hash_next) > - { > - if (strcmp (MSYMBOL_LINKAGE_NAME (msym), name) == 0) > - { > - result.minsym = msym; > - result.objfile = objfile; > - return result; > - } > - } > + result = lookup_minimal_symbol (name, NULL, objfile); > + if (result.minsym != NULL) > + return result; > } > > memset (&result, 0, sizeof (result)); ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PING][PATCH PR gdb/18071] TLS variables can't be resolved on aarch64-linux-gnu 2017-11-16 1:53 ` [PING][PATCH PR gdb/18071] TLS variables can't be resolved on aarch64-linux-gnu Wei-min Pan @ 2018-01-16 17:12 ` Yao Qi 2018-01-17 1:05 ` Weimin Pan 0 siblings, 1 reply; 12+ messages in thread From: Yao Qi @ 2018-01-16 17:12 UTC (permalink / raw) To: Wei-min Pan; +Cc: gdb-patches Wei-min Pan <weimin.pan@oracle.com> writes: >> Function info_address_command() handles the "info address" command and >> calls lookup_minimal_symbol_and_objfile() to find sym's symbol entry in >> mininal symbol table if SYMBOL_COMPUTED_OPS (sym) is false. Problem is >> that function lookup_minimal_symbol_and_objfile() only looked up an >> objfile's minsym ordinary hash table, not its demangled hash table, which >> was the reason why the C++ name was not found. lookup_minimal_symbol_and_objfile is documented as "only checks the linkage name" in minsyms.h, /* Find the minimal symbol named NAME, and return both the minsym struct and its objfile. This only checks the linkage name. */ struct bound_minimal_symbol lookup_minimal_symbol_and_objfile (const char *); >> >> The fix is to call lookup_minimal_symbol(), which already looks up entries >> in both minsym's hash tables, to find names when traversing the object file >> list in lookup_minimal_symbol_and_objfile(). so, it is incorrect to extend it to search demangled name. If I set a breakpoint on lookup_minimal_symbol_and_objfile, (gdb) info address K::another_thread_local Breakpoint 1, lookup_minimal_symbol_and_objfile (name=0x621000136e40 "K::another_thread_local") at gdb/minsyms.c:1012 1012 unsigned int hash = msymbol_hash (name) % MINIMAL_SYMBOL_HASH_SIZE; (gdb) up #1 0x0000000000af7690 in info_address_command (exp=0x604000023f5d "K::another_thread_local", from_tty=1) at gdb/printcmd.c:1567 1567 msym = lookup_minimal_symbol_and_objfile (SYMBOL_LINKAGE_NAME (sym)); The problem to me is that why SYMBOL_LINKAGE_NAME (sym) is "K::another_thread_local", which is a demangled one. The symbol's name is set in dwarf2read.c:new_symbol_full, /* Cache this symbol's name and the name's demangled form (if any). */ SYMBOL_SET_LANGUAGE (sym, cu->language, &objfile->objfile_obstack); linkagename = dwarf2_physname (name, die, cu); SYMBOL_SET_NAMES (sym, linkagename, strlen (linkagename), 0, objfile); however, dwarf2_physname doesn't return the linkage name, so the symbol's linkagename is set incorrectly. I think the right fix would be call other function to get linkagename, maybe, dw2_linkage_name? I don't know. -- Yao (齐尧) ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PING][PATCH PR gdb/18071] TLS variables can't be resolved on aarch64-linux-gnu 2018-01-16 17:12 ` Yao Qi @ 2018-01-17 1:05 ` Weimin Pan 2018-01-17 8:57 ` Yao Qi 0 siblings, 1 reply; 12+ messages in thread From: Weimin Pan @ 2018-01-17 1:05 UTC (permalink / raw) To: Yao Qi; +Cc: gdb-patches On 1/16/2018 9:12 AM, Yao Qi wrote: > Wei-min Pan <weimin.pan@oracle.com> writes: > >>> Function info_address_command() handles the "info address" command and >>> calls lookup_minimal_symbol_and_objfile() to find sym's symbol entry in >>> mininal symbol table if SYMBOL_COMPUTED_OPS (sym) is false. Problem is >>> that function lookup_minimal_symbol_and_objfile() only looked up an >>> objfile's minsym ordinary hash table, not its demangled hash table, which >>> was the reason why the C++ name was not found. > lookup_minimal_symbol_and_objfile is documented as "only checks the > linkage name" in minsyms.h, > > /* Find the minimal symbol named NAME, and return both the minsym > struct and its objfile. This only checks the linkage name. */ > > struct bound_minimal_symbol lookup_minimal_symbol_and_objfile (const char *); > >>> The fix is to call lookup_minimal_symbol(), which already looks up entries >>> in both minsym's hash tables, to find names when traversing the object file >>> list in lookup_minimal_symbol_and_objfile(). > so, it is incorrect to extend it to search demangled name. If I set a > breakpoint on lookup_minimal_symbol_and_objfile, > > (gdb) info address K::another_thread_local > > Breakpoint 1, lookup_minimal_symbol_and_objfile (name=0x621000136e40 "K::another_thread_local") at gdb/minsyms.c:1012 > 1012 unsigned int hash = msymbol_hash (name) % MINIMAL_SYMBOL_HASH_SIZE; > (gdb) up > #1 0x0000000000af7690 in info_address_command (exp=0x604000023f5d "K::another_thread_local", from_tty=1) > at gdb/printcmd.c:1567 > 1567 msym = lookup_minimal_symbol_and_objfile (SYMBOL_LINKAGE_NAME (sym)); > > The problem to me is that why SYMBOL_LINKAGE_NAME (sym) is > "K::another_thread_local", which is a demangled one. The symbol's name > is set in dwarf2read.c:new_symbol_full, > > /* Cache this symbol's name and the name's demangled form (if any). */ > SYMBOL_SET_LANGUAGE (sym, cu->language, &objfile->objfile_obstack); > linkagename = dwarf2_physname (name, die, cu); > SYMBOL_SET_NAMES (sym, linkagename, strlen (linkagename), 0, objfile); > > however, dwarf2_physname doesn't return the linkage name, so the > symbol's linkagename is set incorrectly. I think the right fix would be > call other function to get linkagename, maybe, dw2_linkage_name? I > don't know. dwarf2_physname() does call dw2_linkage_name(). But since the class member, i.e. another_thread_local, does not contain either DW_AT_linkage_name or DW_AT_MIPS_linkage_name attribute, its canonicalized name gets returned. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PING][PATCH PR gdb/18071] TLS variables can't be resolved on aarch64-linux-gnu 2018-01-17 1:05 ` Weimin Pan @ 2018-01-17 8:57 ` Yao Qi 2018-01-18 0:18 ` Wei-min Pan 0 siblings, 1 reply; 12+ messages in thread From: Yao Qi @ 2018-01-17 8:57 UTC (permalink / raw) To: Weimin Pan; +Cc: gdb-patches On Wed, Jan 17, 2018 at 1:05 AM, Weimin Pan <weimin.pan@oracle.com> wrote: > > dwarf2_physname() does call dw2_linkage_name(). But since the class member, > i.e. another_thread_local, does not contain either DW_AT_linkage_name or > DW_AT_MIPS_linkage_name attribute, its canonicalized name gets returned. > dwarf2_physname is called twice with the parameter NAME is "another_thread_local". The first is about DW_TAG_member and the second is about DW_TAG_variable. <2><37>: Abbrev Number: 3 (DW_TAG_member) <38> DW_AT_name : (indirect string, offset: 0x6e): another_thread_local <3c> DW_AT_decl_file : 1 <3d> DW_AT_decl_line : 3 <3e> DW_AT_type : <0x44> <42> DW_AT_external : 1 <42> DW_AT_accessibility: 1 (public) <43> DW_AT_declaration : 1 .... <1><68>: Abbrev Number: 6 (DW_TAG_variable) <69> DW_AT_specification: <0x37> <6d> DW_AT_decl_line : 6 <6e> DW_AT_linkage_name: (indirect string, offset: 0x0): _ZN1K20another_thread_localE The second one matters, not the first one. If I set this breakpoint, it will hit twice, (gdb) b dwarf2_physname if strcmp (name, "another_thread_local") == 0 in the 2nd breakpoint hit, you can see dwarf2_physname is called by new_symbol_full, (gdb) bt 5 #0 dwarf2_physname (name=0x60d0000096fe "another_thread_local", die=0x621000156ce0, cu=0x612000018340) at gdb/dwarf2read.c:11183 #1 0x00000000008f20a9 in new_symbol_full (die=0x621000156ce0, type=0x0, cu=0x612000018340, space=0x0) at gdb/dwarf2read.c:21416 #2 0x00000000008c80a6 in read_variable (die=0x621000156ce0, cu=0x612000018340) at gdb/dwarf2read.c:14439 it returns "K::another_thread_local", and use it to set symbol name. That symbol is used in lookup_minimal_symbol_and_objfile (SYMBOL_LINKAGE_NAME (sym)) later when you type command "info address K::another_thread_local". -- Yao (齐尧) ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PING][PATCH PR gdb/18071] TLS variables can't be resolved on aarch64-linux-gnu 2018-01-17 8:57 ` Yao Qi @ 2018-01-18 0:18 ` Wei-min Pan 0 siblings, 0 replies; 12+ messages in thread From: Wei-min Pan @ 2018-01-18 0:18 UTC (permalink / raw) To: Yao Qi; +Cc: gdb-patches On 1/17/2018 12:55 AM, Yao Qi wrote: > On Wed, Jan 17, 2018 at 1:05 AM, Weimin Pan <weimin.pan@oracle.com> wrote: >> dwarf2_physname() does call dw2_linkage_name(). But since the class member, >> i.e. another_thread_local, does not contain either DW_AT_linkage_name or >> DW_AT_MIPS_linkage_name attribute, its canonicalized name gets returned. >> > dwarf2_physname is called twice with the parameter NAME is > "another_thread_local". > The first is about DW_TAG_member and the second is about DW_TAG_variable. > > <2><37>: Abbrev Number: 3 (DW_TAG_member) > <38> DW_AT_name : (indirect string, offset: 0x6e): > another_thread_local > <3c> DW_AT_decl_file : 1 > <3d> DW_AT_decl_line : 3 > <3e> DW_AT_type : <0x44> > <42> DW_AT_external : 1 > <42> DW_AT_accessibility: 1 (public) > <43> DW_AT_declaration : 1 > .... > <1><68>: Abbrev Number: 6 (DW_TAG_variable) > <69> DW_AT_specification: <0x37> > <6d> DW_AT_decl_line : 6 > <6e> DW_AT_linkage_name: (indirect string, offset: 0x0): > _ZN1K20another_thread_localE > > The second one matters, not the first one. If I set this breakpoint, > it will hit twice, > > (gdb) b dwarf2_physname if strcmp (name, "another_thread_local") == 0 > > in the 2nd breakpoint hit, you can see dwarf2_physname is called by > new_symbol_full, > > (gdb) bt 5 > #0 dwarf2_physname (name=0x60d0000096fe "another_thread_local", > die=0x621000156ce0, cu=0x612000018340) > at gdb/dwarf2read.c:11183 > #1 0x00000000008f20a9 in new_symbol_full (die=0x621000156ce0, > type=0x0, cu=0x612000018340, space=0x0) > at gdb/dwarf2read.c:21416 > #2 0x00000000008c80a6 in read_variable (die=0x621000156ce0, > cu=0x612000018340) at gdb/dwarf2read.c:14439 > > it returns "K::another_thread_local", and use it to set symbol name. > That symbol > is used in lookup_minimal_symbol_and_objfile (SYMBOL_LINKAGE_NAME (sym)) > later when you type command "info address K::another_thread_local". Yes, the 2nd breakpoint hit in dwarf2_physname() was to handle the DW_TAG_variable die for another_thread_local. The function did fetch the correct mangled name from dw2_linkage_name() and set it in local variable "mangled". Problem is "mangled" got demangled with gdb_demangle(), for the purpose of suppressing C++ template function's return type which I don't quite follow, and the demangled name gets returned. ^ permalink raw reply [flat|nested] 12+ messages in thread
[parent not found: <515b875f-8240-b7e0-f5cc-4a26efb64b89@oracle.com>]
* Re: [PING 2][PATCH PR gdb/18071] TLS variables can't be resolved on aarch64-linux-gnu [not found] ` <515b875f-8240-b7e0-f5cc-4a26efb64b89@oracle.com> @ 2018-01-12 23:59 ` Weimin Pan [not found] ` <64a638db-13e1-e692-f775-9afc19677a2a@oracle.com> 1 sibling, 0 replies; 12+ messages in thread From: Weimin Pan @ 2018-01-12 23:59 UTC (permalink / raw) To: gdb-patches On 11/15/2017 5:51 PM, Wei-min Pan wrote: > > On 11/2/2017 8:32 AM, Weimin Pan wrote: >> Running the test case with upstream gdb shows two failures: >> >> (1) Receiving different error messages when printing TLS variable before >>     program runs - because the ARM compiler does not emit dwarf >> attribute >>     DW_AT_location for TLS, the result is expected and the baseline may >>     need to be changed for aarch64. >> >> (2) Using "info address" command on C++ static TLS object resulted in >>     "symbol unresolved" error - below is a snippet from the test case: >> >> class K { >>  public: >>   static __thread int another_thread_local; >> }; >> >> __thread int K::another_thread_local; >> >> (gdb) info address K::another_thread_local >> Symbol "K::another_thread_local" is unresolved. >> >> This patch contains fix for (2). >> >> Function info_address_command() handles the "info address" command and >> calls lookup_minimal_symbol_and_objfile() to find sym's symbol entry in >> mininal symbol table if SYMBOL_COMPUTED_OPS (sym) is false. Problem is >> that function lookup_minimal_symbol_and_objfile() only looked up an >> objfile's minsym ordinary hash table, not its demangled hash table, >> which >> was the reason why the C++ name was not found. >> >> The fix is to call lookup_minimal_symbol(), which already looks up >> entries >> in both minsym's hash tables, to find names when traversing the >> object file >> list in lookup_minimal_symbol_and_objfile(). >> >> Tested in both aarch64-linux-gnu and amd64-linux-gnu. No regressions. >> --- >>  gdb/ChangeLog |   5 +++++ >>  gdb/minsyms.c |  17 +++-------------- >>  2 files changed, 8 insertions(+), 14 deletions(-) >> >> diff --git a/gdb/ChangeLog b/gdb/ChangeLog >> index 4b292e0..2f630bc 100644 >> --- a/gdb/ChangeLog >> +++ b/gdb/ChangeLog >> @@ -1,3 +1,8 @@ >> +2017-11-01 Weimin Pan <weimin.pan@oracle.com> >> + >> +   * minsyms.c (lookup_minimal_symbol_and_objfile): Use >> +   lookup_minimal_symbol() to find symbol entry. >> + >>  2017-10-27 Keith Seitz <keiths@redhat.com> >>       * breakpoint.c (print_breakpoint_location): Use the symbol saved >> diff --git a/gdb/minsyms.c b/gdb/minsyms.c >> index 37edbd8..4edd8b1 100644 >> --- a/gdb/minsyms.c >> +++ b/gdb/minsyms.c >> @@ -881,23 +881,12 @@ lookup_minimal_symbol_and_objfile (const char >> *name) >>  { >>    struct bound_minimal_symbol result; >>    struct objfile *objfile; >> - unsigned int hash = msymbol_hash (name) % MINIMAL_SYMBOL_HASH_SIZE; >>     ALL_OBJFILES (objfile) >>      { >> -     struct minimal_symbol *msym; >> - >> -     for (msym = objfile->per_bfd->msymbol_hash[hash]; >> -      msym != NULL; >> -      msym = msym->hash_next) >> -   { >> -     if (strcmp (MSYMBOL_LINKAGE_NAME (msym), name) == 0) >> -       { >> -         result.minsym = msym; >> -         result.objfile = objfile; >> -         return result; >> -       } >> -   } >> +     result = lookup_minimal_symbol (name, NULL, objfile); >> +     if (result.minsym != NULL) >> +       return result; >>      } >>     memset (&result, 0, sizeof (result)); > ^ permalink raw reply [flat|nested] 12+ messages in thread
[parent not found: <64a638db-13e1-e692-f775-9afc19677a2a@oracle.com>]
* Re: [PING 3][PATCH PR gdb/18071] TLS variables can't be resolved on aarch64-linux-gnu [not found] ` <64a638db-13e1-e692-f775-9afc19677a2a@oracle.com> @ 2018-01-24 1:11 ` Weimin Pan 2018-02-06 1:21 ` [PING 4][PATCH " Weimin Pan 0 siblings, 1 reply; 12+ messages in thread From: Weimin Pan @ 2018-01-24 1:11 UTC (permalink / raw) To: gdb-patches; +Cc: Wei-min Pan While this problem shows up in aarch64, the fix is actually in gdb core. Pedro, would you please review the patch when you get a chance? Thanks. On 1/11/2018 4:32 PM, Wei-min Pan wrote: > > On 11/15/2017 5:51 PM, Wei-min Pan wrote: >> >> On 11/2/2017 8:32 AM, Weimin Pan wrote: >>> Running the test case with upstream gdb shows two failures: >>> >>> (1) Receiving different error messages when printing TLS variable >>> before >>>     program runs - because the ARM compiler does not emit dwarf >>> attribute >>>     DW_AT_location for TLS, the result is expected and the baseline >>> may >>>     need to be changed for aarch64. >>> >>> (2) Using "info address" command on C++ static TLS object resulted in >>>     "symbol unresolved" error - below is a snippet from the test case: >>> >>> class K { >>>  public: >>>   static __thread int another_thread_local; >>> }; >>> >>> __thread int K::another_thread_local; >>> >>> (gdb) info address K::another_thread_local >>> Symbol "K::another_thread_local" is unresolved. >>> >>> This patch contains fix for (2). >>> >>> Function info_address_command() handles the "info address" command and >>> calls lookup_minimal_symbol_and_objfile() to find sym's symbol entry in >>> mininal symbol table if SYMBOL_COMPUTED_OPS (sym) is false. Problem is >>> that function lookup_minimal_symbol_and_objfile() only looked up an >>> objfile's minsym ordinary hash table, not its demangled hash table, >>> which >>> was the reason why the C++ name was not found. >>> >>> The fix is to call lookup_minimal_symbol(), which already looks up >>> entries >>> in both minsym's hash tables, to find names when traversing the >>> object file >>> list in lookup_minimal_symbol_and_objfile(). >>> >>> Tested in both aarch64-linux-gnu and amd64-linux-gnu. No regressions. >>> --- >>>  gdb/ChangeLog |   5 +++++ >>>  gdb/minsyms.c |  17 +++-------------- >>>  2 files changed, 8 insertions(+), 14 deletions(-) >>> >>> diff --git a/gdb/ChangeLog b/gdb/ChangeLog >>> index 4b292e0..2f630bc 100644 >>> --- a/gdb/ChangeLog >>> +++ b/gdb/ChangeLog >>> @@ -1,3 +1,8 @@ >>> +2017-11-01 Weimin Pan <weimin.pan@oracle.com> >>> + >>> +   * minsyms.c (lookup_minimal_symbol_and_objfile): Use >>> +   lookup_minimal_symbol() to find symbol entry. >>> + >>>  2017-10-27 Keith Seitz <keiths@redhat.com> >>>       * breakpoint.c (print_breakpoint_location): Use the symbol >>> saved >>> diff --git a/gdb/minsyms.c b/gdb/minsyms.c >>> index 37edbd8..4edd8b1 100644 >>> --- a/gdb/minsyms.c >>> +++ b/gdb/minsyms.c >>> @@ -881,23 +881,12 @@ lookup_minimal_symbol_and_objfile (const char >>> *name) >>>  { >>>    struct bound_minimal_symbol result; >>>    struct objfile *objfile; >>> - unsigned int hash = msymbol_hash (name) % MINIMAL_SYMBOL_HASH_SIZE; >>>     ALL_OBJFILES (objfile) >>>      { >>> -     struct minimal_symbol *msym; >>> - >>> -     for (msym = objfile->per_bfd->msymbol_hash[hash]; >>> -      msym != NULL; >>> -      msym = msym->hash_next) >>> -   { >>> -     if (strcmp (MSYMBOL_LINKAGE_NAME (msym), name) == 0) >>> -       { >>> -         result.minsym = msym; >>> -         result.objfile = objfile; >>> -         return result; >>> -       } >>> -   } >>> +     result = lookup_minimal_symbol (name, NULL, objfile); >>> +     if (result.minsym != NULL) >>> +       return result; >>>      } >>>     memset (&result, 0, sizeof (result)); >> > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PING 4][PATCH PR gdb/18071] TLS variables can't be resolved on aarch64-linux-gnu 2018-01-24 1:11 ` [PING 3][PATCH " Weimin Pan @ 2018-02-06 1:21 ` Weimin Pan 2018-03-06 1:21 ` [PING 5][PATCH " Weimin Pan 0 siblings, 1 reply; 12+ messages in thread From: Weimin Pan @ 2018-02-06 1:21 UTC (permalink / raw) To: gdb-patches On 1/23/2018 5:11 PM, Weimin Pan wrote: > While this problem shows up in aarch64, the fix is actually > in gdb core. Pedro, would you please review the patch when > you get a chance? > > Thanks. > > On 1/11/2018 4:32 PM, Wei-min Pan wrote: >> >> On 11/15/2017 5:51 PM, Wei-min Pan wrote: >>> >>> On 11/2/2017 8:32 AM, Weimin Pan wrote: >>>> Running the test case with upstream gdb shows two failures: >>>> >>>> (1) Receiving different error messages when printing TLS variable >>>> before >>>>     program runs - because the ARM compiler does not emit dwarf >>>> attribute >>>>     DW_AT_location for TLS, the result is expected and the >>>> baseline may >>>>     need to be changed for aarch64. >>>> >>>> (2) Using "info address" command on C++ static TLS object resulted in >>>>     "symbol unresolved" error - below is a snippet from the test >>>> case: >>>> >>>> class K { >>>>  public: >>>>   static __thread int another_thread_local; >>>> }; >>>> >>>> __thread int K::another_thread_local; >>>> >>>> (gdb) info address K::another_thread_local >>>> Symbol "K::another_thread_local" is unresolved. >>>> >>>> This patch contains fix for (2). >>>> >>>> Function info_address_command() handles the "info address" command and >>>> calls lookup_minimal_symbol_and_objfile() to find sym's symbol >>>> entry in >>>> mininal symbol table if SYMBOL_COMPUTED_OPS (sym) is false. Problem is >>>> that function lookup_minimal_symbol_and_objfile() only looked up an >>>> objfile's minsym ordinary hash table, not its demangled hash table, >>>> which >>>> was the reason why the C++ name was not found. >>>> >>>> The fix is to call lookup_minimal_symbol(), which already looks up >>>> entries >>>> in both minsym's hash tables, to find names when traversing the >>>> object file >>>> list in lookup_minimal_symbol_and_objfile(). >>>> >>>> Tested in both aarch64-linux-gnu and amd64-linux-gnu. No regressions. >>>> --- >>>>  gdb/ChangeLog |   5 +++++ >>>>  gdb/minsyms.c |  17 +++-------------- >>>>  2 files changed, 8 insertions(+), 14 deletions(-) >>>> >>>> diff --git a/gdb/ChangeLog b/gdb/ChangeLog >>>> index 4b292e0..2f630bc 100644 >>>> --- a/gdb/ChangeLog >>>> +++ b/gdb/ChangeLog >>>> @@ -1,3 +1,8 @@ >>>> +2017-11-01 Weimin Pan <weimin.pan@oracle.com> >>>> + >>>> +   * minsyms.c (lookup_minimal_symbol_and_objfile): Use >>>> +   lookup_minimal_symbol() to find symbol entry. >>>> + >>>>  2017-10-27 Keith Seitz <keiths@redhat.com> >>>>       * breakpoint.c (print_breakpoint_location): Use the symbol >>>> saved >>>> diff --git a/gdb/minsyms.c b/gdb/minsyms.c >>>> index 37edbd8..4edd8b1 100644 >>>> --- a/gdb/minsyms.c >>>> +++ b/gdb/minsyms.c >>>> @@ -881,23 +881,12 @@ lookup_minimal_symbol_and_objfile (const char >>>> *name) >>>>  { >>>>    struct bound_minimal_symbol result; >>>>    struct objfile *objfile; >>>> - unsigned int hash = msymbol_hash (name) % MINIMAL_SYMBOL_HASH_SIZE; >>>>     ALL_OBJFILES (objfile) >>>>      { >>>> -     struct minimal_symbol *msym; >>>> - >>>> -     for (msym = objfile->per_bfd->msymbol_hash[hash]; >>>> -      msym != NULL; >>>> -      msym = msym->hash_next) >>>> -   { >>>> -     if (strcmp (MSYMBOL_LINKAGE_NAME (msym), name) == 0) >>>> -       { >>>> -         result.minsym = msym; >>>> -         result.objfile = objfile; >>>> -         return result; >>>> -       } >>>> -   } >>>> +     result = lookup_minimal_symbol (name, NULL, objfile); >>>> +     if (result.minsym != NULL) >>>> +       return result; >>>>      } >>>>     memset (&result, 0, sizeof (result)); >>> >> > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PING 5][PATCH PR gdb/18071] TLS variables can't be resolved on aarch64-linux-gnu 2018-02-06 1:21 ` [PING 4][PATCH " Weimin Pan @ 2018-03-06 1:21 ` Weimin Pan 2018-03-13 18:56 ` [PING 6][PATCH " Weimin Pan 0 siblings, 1 reply; 12+ messages in thread From: Weimin Pan @ 2018-03-06 1:21 UTC (permalink / raw) To: gdb-patches On 2/5/2018 5:21 PM, Weimin Pan wrote: > On 1/23/2018 5:11 PM, Weimin Pan wrote: >> While this problem shows up in aarch64, the fix is actually >> in gdb core. Pedro, would you please review the patch when >> you get a chance? >> >> Thanks. >> >> On 1/11/2018 4:32 PM, Wei-min Pan wrote: >>> >>> On 11/15/2017 5:51 PM, Wei-min Pan wrote: >>>> >>>> On 11/2/2017 8:32 AM, Weimin Pan wrote: >>>>> Running the test case with upstream gdb shows two failures: >>>>> >>>>> (1) Receiving different error messages when printing TLS variable >>>>> before >>>>>     program runs - because the ARM compiler does not emit dwarf >>>>> attribute >>>>>     DW_AT_location for TLS, the result is expected and the >>>>> baseline may >>>>>     need to be changed for aarch64. >>>>> >>>>> (2) Using "info address" command on C++ static TLS object resulted in >>>>>     "symbol unresolved" error - below is a snippet from the test >>>>> case: >>>>> >>>>> class K { >>>>>  public: >>>>>   static __thread int another_thread_local; >>>>> }; >>>>> >>>>> __thread int K::another_thread_local; >>>>> >>>>> (gdb) info address K::another_thread_local >>>>> Symbol "K::another_thread_local" is unresolved. >>>>> >>>>> This patch contains fix for (2). >>>>> >>>>> Function info_address_command() handles the "info address" command >>>>> and >>>>> calls lookup_minimal_symbol_and_objfile() to find sym's symbol >>>>> entry in >>>>> mininal symbol table if SYMBOL_COMPUTED_OPS (sym) is false. >>>>> Problem is >>>>> that function lookup_minimal_symbol_and_objfile() only looked up an >>>>> objfile's minsym ordinary hash table, not its demangled hash >>>>> table, which >>>>> was the reason why the C++ name was not found. >>>>> >>>>> The fix is to call lookup_minimal_symbol(), which already looks up >>>>> entries >>>>> in both minsym's hash tables, to find names when traversing the >>>>> object file >>>>> list in lookup_minimal_symbol_and_objfile(). >>>>> >>>>> Tested in both aarch64-linux-gnu and amd64-linux-gnu. No regressions. >>>>> --- >>>>>  gdb/ChangeLog |   5 +++++ >>>>>  gdb/minsyms.c |  17 +++-------------- >>>>>  2 files changed, 8 insertions(+), 14 deletions(-) >>>>> >>>>> diff --git a/gdb/ChangeLog b/gdb/ChangeLog >>>>> index 4b292e0..2f630bc 100644 >>>>> --- a/gdb/ChangeLog >>>>> +++ b/gdb/ChangeLog >>>>> @@ -1,3 +1,8 @@ >>>>> +2017-11-01 Weimin Pan <weimin.pan@oracle.com> >>>>> + >>>>> +   * minsyms.c (lookup_minimal_symbol_and_objfile): Use >>>>> +   lookup_minimal_symbol() to find symbol entry. >>>>> + >>>>>  2017-10-27 Keith Seitz <keiths@redhat.com> >>>>>       * breakpoint.c (print_breakpoint_location): Use the symbol >>>>> saved >>>>> diff --git a/gdb/minsyms.c b/gdb/minsyms.c >>>>> index 37edbd8..4edd8b1 100644 >>>>> --- a/gdb/minsyms.c >>>>> +++ b/gdb/minsyms.c >>>>> @@ -881,23 +881,12 @@ lookup_minimal_symbol_and_objfile (const >>>>> char *name) >>>>>  { >>>>>    struct bound_minimal_symbol result; >>>>>    struct objfile *objfile; >>>>> - unsigned int hash = msymbol_hash (name) % >>>>> MINIMAL_SYMBOL_HASH_SIZE; >>>>>     ALL_OBJFILES (objfile) >>>>>      { >>>>> -     struct minimal_symbol *msym; >>>>> - >>>>> -     for (msym = objfile->per_bfd->msymbol_hash[hash]; >>>>> -      msym != NULL; >>>>> -      msym = msym->hash_next) >>>>> -   { >>>>> -     if (strcmp (MSYMBOL_LINKAGE_NAME (msym), name) == 0) >>>>> -       { >>>>> -         result.minsym = msym; >>>>> -         result.objfile = objfile; >>>>> -         return result; >>>>> -       } >>>>> -   } >>>>> +     result = lookup_minimal_symbol (name, NULL, objfile); >>>>> +     if (result.minsym != NULL) >>>>> +       return result; >>>>>      } >>>>>     memset (&result, 0, sizeof (result)); >>>> >>> >> > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PING 6][PATCH PR gdb/18071] TLS variables can't be resolved on aarch64-linux-gnu 2018-03-06 1:21 ` [PING 5][PATCH " Weimin Pan @ 2018-03-13 18:56 ` Weimin Pan 2018-03-14 21:06 ` Simon Marchi 0 siblings, 1 reply; 12+ messages in thread From: Weimin Pan @ 2018-03-13 18:56 UTC (permalink / raw) To: gdb-patches On 3/5/2018 5:19 PM, Weimin Pan wrote: > > > On 2/5/2018 5:21 PM, Weimin Pan wrote: >> On 1/23/2018 5:11 PM, Weimin Pan wrote: >>> While this problem shows up in aarch64, the fix is actually >>> in gdb core. Pedro, would you please review the patch when >>> you get a chance? >>> >>> Thanks. >>> >>> On 1/11/2018 4:32 PM, Wei-min Pan wrote: >>>> >>>> On 11/15/2017 5:51 PM, Wei-min Pan wrote: >>>>> >>>>> On 11/2/2017 8:32 AM, Weimin Pan wrote: >>>>>> Running the test case with upstream gdb shows two failures: >>>>>> >>>>>> (1) Receiving different error messages when printing TLS variable >>>>>> before >>>>>>     program runs - because the ARM compiler does not emit dwarf >>>>>> attribute >>>>>>     DW_AT_location for TLS, the result is expected and the >>>>>> baseline may >>>>>>     need to be changed for aarch64. >>>>>> >>>>>> (2) Using "info address" command on C++ static TLS object >>>>>> resulted in >>>>>>     "symbol unresolved" error - below is a snippet from the test >>>>>> case: >>>>>> >>>>>> class K { >>>>>>  public: >>>>>>   static __thread int another_thread_local; >>>>>> }; >>>>>> >>>>>> __thread int K::another_thread_local; >>>>>> >>>>>> (gdb) info address K::another_thread_local >>>>>> Symbol "K::another_thread_local" is unresolved. >>>>>> >>>>>> This patch contains fix for (2). >>>>>> >>>>>> Function info_address_command() handles the "info address" >>>>>> command and >>>>>> calls lookup_minimal_symbol_and_objfile() to find sym's symbol >>>>>> entry in >>>>>> mininal symbol table if SYMBOL_COMPUTED_OPS (sym) is false. >>>>>> Problem is >>>>>> that function lookup_minimal_symbol_and_objfile() only looked up an >>>>>> objfile's minsym ordinary hash table, not its demangled hash >>>>>> table, which >>>>>> was the reason why the C++ name was not found. >>>>>> >>>>>> The fix is to call lookup_minimal_symbol(), which already looks >>>>>> up entries >>>>>> in both minsym's hash tables, to find names when traversing the >>>>>> object file >>>>>> list in lookup_minimal_symbol_and_objfile(). >>>>>> >>>>>> Tested in both aarch64-linux-gnu and amd64-linux-gnu. No >>>>>> regressions. >>>>>> --- >>>>>>  gdb/ChangeLog |   5 +++++ >>>>>>  gdb/minsyms.c |  17 +++-------------- >>>>>>  2 files changed, 8 insertions(+), 14 deletions(-) >>>>>> >>>>>> diff --git a/gdb/ChangeLog b/gdb/ChangeLog >>>>>> index 4b292e0..2f630bc 100644 >>>>>> --- a/gdb/ChangeLog >>>>>> +++ b/gdb/ChangeLog >>>>>> @@ -1,3 +1,8 @@ >>>>>> +2017-11-01 Weimin Pan <weimin.pan@oracle.com> >>>>>> + >>>>>> +   * minsyms.c (lookup_minimal_symbol_and_objfile): Use >>>>>> +   lookup_minimal_symbol() to find symbol entry. >>>>>> + >>>>>>  2017-10-27 Keith Seitz <keiths@redhat.com> >>>>>>       * breakpoint.c (print_breakpoint_location): Use the >>>>>> symbol saved >>>>>> diff --git a/gdb/minsyms.c b/gdb/minsyms.c >>>>>> index 37edbd8..4edd8b1 100644 >>>>>> --- a/gdb/minsyms.c >>>>>> +++ b/gdb/minsyms.c >>>>>> @@ -881,23 +881,12 @@ lookup_minimal_symbol_and_objfile (const >>>>>> char *name) >>>>>>  { >>>>>>    struct bound_minimal_symbol result; >>>>>>    struct objfile *objfile; >>>>>> - unsigned int hash = msymbol_hash (name) % >>>>>> MINIMAL_SYMBOL_HASH_SIZE; >>>>>>     ALL_OBJFILES (objfile) >>>>>>      { >>>>>> -     struct minimal_symbol *msym; >>>>>> - >>>>>> -     for (msym = objfile->per_bfd->msymbol_hash[hash]; >>>>>> -      msym != NULL; >>>>>> -      msym = msym->hash_next) >>>>>> -   { >>>>>> -     if (strcmp (MSYMBOL_LINKAGE_NAME (msym), name) == 0) >>>>>> -       { >>>>>> -         result.minsym = msym; >>>>>> -         result.objfile = objfile; >>>>>> -         return result; >>>>>> -       } >>>>>> -   } >>>>>> +     result = lookup_minimal_symbol (name, NULL, objfile); >>>>>> +     if (result.minsym != NULL) >>>>>> +       return result; >>>>>>      } >>>>>>     memset (&result, 0, sizeof (result)); >>>>> >>>> >>> >> > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PING 6][PATCH PR gdb/18071] TLS variables can't be resolved on aarch64-linux-gnu 2018-03-13 18:56 ` [PING 6][PATCH " Weimin Pan @ 2018-03-14 21:06 ` Simon Marchi 2018-03-14 21:34 ` Wei-min Pan 0 siblings, 1 reply; 12+ messages in thread From: Simon Marchi @ 2018-03-14 21:06 UTC (permalink / raw) To: Weimin Pan; +Cc: gdb-patches Hi Weimin, This is just to tell you that I started looking into this, since Yao will likely not have the time to do it (though I don't mind if he does!). But it might take a bit of time since I don't know much about the particular case of TLS on aarch64, so I'll need to ramp up on it. Simon ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PING 6][PATCH PR gdb/18071] TLS variables can't be resolved on aarch64-linux-gnu 2018-03-14 21:06 ` Simon Marchi @ 2018-03-14 21:34 ` Wei-min Pan 0 siblings, 0 replies; 12+ messages in thread From: Wei-min Pan @ 2018-03-14 21:34 UTC (permalink / raw) To: Simon Marchi; +Cc: gdb-patches Hi Simon, Thanks for taking this up. Yao did take a look at the patch late last year but didn't have time to finish it up. Please let me know if you have comments/questions. Weimin On 3/14/2018 2:06 PM, Simon Marchi wrote: > Hi Weimin, > > This is just to tell you that I started looking into this, since Yao > will likely not have the time to do it (though I don't mind if he > does!). But it might take a bit of time since I don't know much about > the particular case of TLS on aarch64, so I'll need to ramp up on it. > > Simon ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2018-03-14 21:34 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <1509636764-46111-1-git-send-email-weimin.pan@oracle.com> 2017-11-16 1:53 ` [PING][PATCH PR gdb/18071] TLS variables can't be resolved on aarch64-linux-gnu Wei-min Pan 2018-01-16 17:12 ` Yao Qi 2018-01-17 1:05 ` Weimin Pan 2018-01-17 8:57 ` Yao Qi 2018-01-18 0:18 ` Wei-min Pan [not found] ` <515b875f-8240-b7e0-f5cc-4a26efb64b89@oracle.com> 2018-01-12 23:59 ` [PING 2][PATCH " Weimin Pan [not found] ` <64a638db-13e1-e692-f775-9afc19677a2a@oracle.com> 2018-01-24 1:11 ` [PING 3][PATCH " Weimin Pan 2018-02-06 1:21 ` [PING 4][PATCH " Weimin Pan 2018-03-06 1:21 ` [PING 5][PATCH " Weimin Pan 2018-03-13 18:56 ` [PING 6][PATCH " Weimin Pan 2018-03-14 21:06 ` Simon Marchi 2018-03-14 21:34 ` Wei-min Pan
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).