This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
RE: [PATCH V4] symlookup: improves symbol lookup when a file is specified.
> -----Original Message-----
> From: gdb-patches-owner@sourceware.org [mailto:gdb-patches-
> owner@sourceware.org] On Behalf Of Tedeschi, Walfred
> Sent: Saturday, October 21, 2017 12:47 PM
> To: Pedro Alves <palves@redhat.com>; Simon Marchi
> <simon.marchi@ericsson.com>; Simon Marchi <simon.marchi@polymtl.ca>
> Cc: gdb-patches@sourceware.org
> Subject: RE: [PATCH V4] symlookup: improves symbol lookup when a file is
> specified.
>
> > -----Original Message-----
> > From: Pedro Alves [mailto:palves@redhat.com]
> > Sent: Friday, October 20, 2017 5:29 PM
> > To: Simon Marchi <simon.marchi@ericsson.com>; Tedeschi, Walfred
> > <walfred.tedeschi@intel.com>; Simon Marchi <simon.marchi@polymtl.ca>
> > Cc: gdb-patches@sourceware.org
> > Subject: Re: [PATCH V4] symlookup: improves symbol lookup when a file
> > is specified.
> >
> > On 10/20/2017 03:28 PM, Simon Marchi wrote:
> > > On 2017-10-20 03:45 AM, Tedeschi, Walfred wrote:
> > >> Hi Simon,
> > >>
> > >> Thanks for your review!
> > >> For all the comment above I agree, Thanks again!
> > >>
> > >> For the one below there are different point of views.
> > >> How I see it: Very few sane people will add a symbols in a shared
> > >> library that will collide like the case we presented here. If one
> > >> does so how can the debugger help?
> > >
> > > I think one usual use case is plugins implemented with shared library.
> > > Although the data symbols will commonly be static, and the plugin
> > > will only expose some function symbols.
> > >
> > >> Providing the same value as the runtime or linker does?
> > >> This one user already knows.
> > >> Or providing what the debug information provides as value created
> > >> by the
> > library itself.
> > >> In final end both are right. :|
> > >>
> > >> But when specifying the scope if user is provided the value of the
> > >> debug info it should be easier to spot that there is something
> > >> weird going on
> > in the code.
> > >
> > > I think what you just said summarizes the problem well and I think
> > > it makes
> > sense.
> > > I just don't think I have enough experience about symbol handling to
> > > understand the situation fully. Could another maintainer with more
> > > experience about symbols give the final ok?
> >
> > I disagree. Having
> > (gdb) frame
> > #0 0x000000000040073b in function () at source.c:22
> > (gdb) print foo
> > and:
> > (gdb) print 'source.c':foo
> >
> > show different values when you're stopped in a function in the
> > source.c file would look inconsistent to me.
> >
> > Actually, the patch introduces what looks like a related clear regression to
> me.
> > With the print-file-var.exp test program, try stepping into
> > get_version_2, and printing the this_version_id global. And then type
> finish. Vis:
> >
> > (gdb) s
> > get_version_2 () at gdb.base/print-file-var-lib2.c:22
> > 22 return this_version_id;
> > (gdb) p this_version_id
> > $1 = 203
> > (gdb) finish
> > Run till exit from #0 get_version_2 () at
> > gdb.base/print-file-var-lib2.c:22 0x000000000040073b in main () at
> gdb.base/print-file-var-main.c:24
> > 24 int v2 = get_version_2 ();
> > Value returned is $2 = 104
> > (gdb)
> >
> > GDB says "203", while the program returns "104".
> > That looks like a bug to me. I'd expect the print to show me the
> > current value of the variable in scope.
> >
> > In current master (without the patch), we get:
> >
> > (gdb) s
> > get_version_2 () at gdb.base/print-file-var-lib2.c:22
> > 22 return this_version_id;
> > (gdb) p this_version_id
> > $1 = 104
> > (gdb) finish
> > Run till exit from #0 get_version_2 () at
> > gdb.base/print-file-var-lib2.c:22 0x000000000040073b in main () at
> gdb.base/print-file-var-main.c:24
> > 24 int v2 = get_version_2 ();
> > Value returned is $2 = 104
>
> Hello Pedro,
>
> Thanks a lot for reviewing that!
> I will bring more information related to what debug information provide and
> so on.
> The linker is the cause of this disconnection. In a previous test patch I have
> added a set/show variable switch between.
> Dlopen and linker behavior. I also found that wrong and looking at it again.
>
> I will try to bring more facts with the debug info and memory examination.
>
> In any case actual behavior of master is also wrong for dlopen case!
>
Hello all,
Here we go:
With mainline gdb we have the following scenario:
Stopped at main line 32 in print-file-var-main(testcase)
(gdb) print this_version_id
$1 = 104
This was expected, we are looking at the symbol that the linker and main can see as specified in the global scope.
(gdb) print &this_version_id
$2 = (int *) 0x7ffff7ddb028 <this_version_id>
(gdb) info symbol 0x7ffff7ddb028
this_version_id in section .data of /nfs/iul/disks/iul_team2/wtedesch/_gdb_/extern_gdb/bin/dlopen/gdb/testsuite/outputs/gdb.base/print-file-var/print-file-var-lib1.so
Those two last evaluations prove that we are seem a symbol coming from the first library as expected and done by the linker.
However interestingly if I specify the scope, I get:
(gdb) print &('print-file-var-lib2.c'::this_version_id)
$3 = (int *) 0x7ffff7ddb028 <this_version_id>
(gdb) info symbol 0x7ffff7ddb028
this_version_id in section .data of /nfs/iul/disks/iul_team2/wtedesch/_gdb_/extern_gdb/bin/dlopen/gdb/testsuite/outputs/gdb.base/print-file-var/print-file-var-lib1.so
But I have specified the scope! I am asking specifically that I want the symbol defined in the second library not in the first.
If I use the patch provided than I get:
(gdb) print &('print-file-var-lib2.c'::this_version_id)
$4 = (int *) 0x7ffff7ddb028 <this_version_id>
(gdb) info symbol 0x7ffff7ddb028
this_version_id in section .data of /nfs/iul/disks/iul_team2/wtedesch/_gdb_/extern_gdb/bin/dlopen/gdb/testsuite/outputs/gdb.base/print-file-var/print-file-var-lib1.so
_This was what I've expected. _
With that I _cannot_ say that GDB is doing right in the main line. Basically the test is weak!
The issue is in the symtab.c ~2603:
gdbarch_iterate_over_objfiles_in_search_order
(objfile != NULL ? get_objfile_arch (objfile) : target_gdbarch (),
lookup_symbol_global_iterator_cb, &lookup_data, objfile);
The lookup here is done in the order of the library load, what is right for global symbols, If and only if no scope is provided.
Again user will specify the scope if he has a doubt on how in earth his value is not what is seen in the execution!
I hope this sample run helps in elucidating the problem!
Thanks and regards,
/Fred
> Thanks and regards,
> /Fred
> >
> > Thanks,
> > Pedro Alves
> Intel Deutschland GmbH
> Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
> Tel: +49 89 99 8853-0, www.intel.de
> Managing Directors: Christin Eisenschmid, Christian Lamprechter Chairperson
> of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial
> Register: Amtsgericht Muenchen HRB 186928
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928