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]

Re: [PATCH] Make symbol_set_names a member function


On Thu, Dec 26, 2019 at 10:43 PM Christian Biesinger
<cbiesinger@google.com> wrote:
>
> On Fri, Dec 27, 2019 at 4:02 AM Simon Marchi <simark@simark.ca> wrote:
> >
> > On 2019-12-26 8:09 p.m., Christian Biesinger wrote:
> > > On Thu, Dec 26, 2019 at 6:50 PM Simon Marchi <simark@simark.ca> wrote:
> > >>
> > >> I hacked the code to always enter these ifs and print both the linkage_name
> > >> and the natural_name.  With a C++ test program containing this function:
> > >>
> > >>   int hello(int);
> > >>
> > >> I get:
> > >>
> > >>   linkage_name: hello
> > >>   natural_name: hello
> > >>
> > >> I would have expected linkage_name to be _Z5helloi and the natural_name to be
> > >> hello(int).  Do you know if it's expected for the partial symbol to contain
> > >> just "hello" for both?
> > >
> > > Huh..
> > >
> > > I added a printf in compute_and_set_names and found that there's a
> > > symbol with the mangled name *and* a symbol with the plain name. I
> > > guess that's why? But I don't know what that means...
> >
> > Ok, I see what happens.  The first call to compute_and_set_names
> > is while parsing minimal symbols, by minimal_symbol_reader::install.
> > This one has a mangled linkage name (_Z5helloi).
> >
> > The second call is while creating partial symbols, by add_psymbol_to_bcache.
> > This is the one with the linkage name "hello".  I suppose that's expected,
> > I had never really paid attention to this.
> >
> > There's also a third call, while creating the full blown symbol, with a
> > linkage name of "hello(int)".
> >
> > So the term "linkage_name" in general_symbol_info is perhaps a bit misleading,
> > it makes sense for minimal symbols, but not really for partial and full symbols.
>
> Hm.. maybe I'll look into this some more to understand this better. It
> certainly seems surprising that minsyms behave differently from other
> symbols in this respect?

OK, I looked into this a little bit more...

For partial symbols, the actual DWARF data contains this:
    <2e>   DW_AT_name        : foo
    <35>   DW_AT_linkage_name: (indirect string, offset: 0x5): _Z3fool

And gdb just use the DIE's DW_AT_name as the linkage name for the
partial symbol. I have not checked what happens for full symbols. But
I'm not sure that this difference between minsyms and psymbols is a
good thing :(

Christian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]