RE: [PATCH V4] symlookup: improves symbol lookup when a file is specified.

["Tedeschi, Walfred" <walfred dot tedeschi at intel dot com>]

> -----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!

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