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: Tedeschi, Walfred
> Sent: Monday, October 23, 2017 11:04 AM
> To: Tedeschi, Walfred <walfred.tedeschi@intel.com>; 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: 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/test
> suite/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/test
> suite/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/test
> suite/outputs/gdb.base/print-file-var/print-file-var-lib1.so
>
Sorry Wrong copy, with the patch:
(gdb) info symbol 0x7ffff7bd9028
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-lib2.so
(gdb) print &('print-file-var-lib2.c'::this_version_id)
$4 = (int *) 0x7ffff7bd9028 <this_version_id>
(gdb) info symbol 0x7ffff7bd9028
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-lib2.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