"set foo"

"set foo"

[Eli Zaretskii]

I had a problem today whereby GDB did not recognize a certain struct
when processing a .gdbinit file.  Trying to understand what's going
on, I noticed that after stepping through the program for a while, the
struct became known at some point.

I assume that this is because of delayed reading of the symbol tables,
but my question is about something else.  I noticed that the .gdbinit
file supplied with Emacs has this line at its beginning:

  set main

A comment there says that this is so some variables from the binary
are available when .gdbinit is processed.  I understand that this
command somehow manages to force GDB to read the relevant portions of
the symbol tables, but what I don't understand is what is the
semantics of saying "set foo" in GDB where foo is some function.  What
does this command do, exactly?

TIA

Re: "set foo"

[Joel Brobecker]

>   set main
> 
> A comment there says that this is so some variables from the binary
> are available when .gdbinit is processed.  I understand that this
> command somehow manages to force GDB to read the relevant portions of
> the symbol tables, but what I don't understand is what is the
> semantics of saying "set foo" in GDB where foo is some function.  What
> does this command do, exactly?

I think that "main" is treated as an expression, and this expression
simply returns the address of function main.  For instance, try the
following:

    (gdb) print main

Since it's a "set" command, we then discard the result of the evaluation.

Variable assignments look like they are performed by the "set", but in
reality, it is performed by the language expression evaluator.  You can
obtain just the same effect using a "print" command:

    (top-gdb) print args.argc = 1
    $1 = 1

The latter causes GDB to print the value returned, but that should be
the only difference.

-- 
Joel

Re: "set foo"

[Eli Zaretskii]

> Date: Sat, 24 Apr 2010 17:21:18 -0400
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: gdb@sourceware.org
> 
> I think that "main" is treated as an expression, and this expression
> simply returns the address of function main.  For instance, try the
> following:
> 
>     (gdb) print main
> 
> Since it's a "set" command, we then discard the result of the evaluation.

Thanks.

So using "set foo" to make sure some symbol used by `foo' is loaded by
GDB is a valid technique, is that right?

Re: "set foo"

[Joel Brobecker]

> So using "set foo" to make sure some symbol used by `foo' is loaded by
> GDB is a valid technique, is that right?

I think the answer is yes - I am a little confused by "some symbol used
by `foo'", but I think I get what you are trying to ask. Basically, what
the above does, as a side effect, is make sure that the full symbols
for the unit containing `foo' get loaded.  I am not sure why the person
who added it felt that they needed that, but I have used that technique
as a workaround several times in the past when there was a bug with
psymtab searching...

-- 
Joel

Re: "set foo"

[Eli Zaretskii]

> Date: Sun, 25 Apr 2010 10:43:47 -0400
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: gdb@sourceware.org
> 
> > So using "set foo" to make sure some symbol used by `foo' is loaded by
> > GDB is a valid technique, is that right?
> 
> I think the answer is yes - I am a little confused by "some symbol used
> by `foo'"

The specific use-case is that GDB does not recognize a certain struct;
for example, "ptype struct foo_t" says "No struct type named foo_t".
But if I type "set foo", where `foo' is a function whose code uses
that struct, GDB magically recognizes the struct afterwards.

> but I think I get what you are trying to ask. Basically, what
> the above does, as a side effect, is make sure that the full symbols
> for the unit containing `foo' get loaded.  I am not sure why the person
> who added it felt that they needed that

The reason is probably that .gdbinit in Emacs defines several
user-defined commands that need various symbols for their definition,
such as the number of bits used for Lisp type tags to convert an
opaque Lisp_Object into a pointer to a C struct.

Thanks.

Re: "set foo"

[Tom Tromey]

>>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:

Eli> The specific use-case is that GDB does not recognize a certain struct;
Eli> for example, "ptype struct foo_t" says "No struct type named foo_t".
Eli> But if I type "set foo", where `foo' is a function whose code uses
Eli> that struct, GDB magically recognizes the struct afterwards.

FWIW, this sounds like a gdb bug to me.

I looked at emacs/src/.gdbinit and it seems to me that the types and
variables in question are global (in the sense of, not local to a
function).  So, they should be found without this trick.

Tom

Re: "set foo"

[Eli Zaretskii]

> From: Tom Tromey <tromey@redhat.com>
> Cc: Joel Brobecker <brobecker@adacore.com>, gdb@sourceware.org
> Date: Mon, 26 Apr 2010 10:23:25 -0600
> 
> >>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:
> 
> Eli> The specific use-case is that GDB does not recognize a certain struct;
> Eli> for example, "ptype struct foo_t" says "No struct type named foo_t".
> Eli> But if I type "set foo", where `foo' is a function whose code uses
> Eli> that struct, GDB magically recognizes the struct afterwards.
> 
> FWIW, this sounds like a gdb bug to me.

Could be a GCC bug as well, no?

> I looked at emacs/src/.gdbinit and it seems to me that the types and
> variables in question are global (in the sense of, not local to a
> function).  So, they should be found without this trick.

So you are saying that global types and variables are always loaded by
GDB automatically, not lazily?

RE: "set foo"

[Paul Koning]

> > I looked at emacs/src/.gdbinit and it seems to me that the types and
> > variables in question are global (in the sense of, not local to a
> > function).  So, they should be found without this trick.
> 
> So you are saying that global types and variables are always loaded by
> GDB automatically, not lazily?

I don't think it means that.  The name should always be recognized; the
definition for that name might be loaded lazily.  That's how variable
names are handled, right?  Lazy loading is an optimization;  it should
be transparent to the user (apart from its performance benefits).

	paul

Re: "set foo"

[Tom Tromey]

>>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:

>> FWIW, this sounds like a gdb bug to me.

Eli> Could be a GCC bug as well, no?

I suppose so.  It is hard to say without more info.

>> I looked at emacs/src/.gdbinit and it seems to me that the types and
>> variables in question are global (in the sense of, not local to a
>> function).  So, they should be found without this trick.

Eli> So you are saying that global types and variables are always loaded by
Eli> GDB automatically, not lazily?

I can only say what happens for DWARF debuginfo, I don't know anything
about the other formats.  (I gather stabs is similar, but I don't know
details.)

For DWARF, GDB does two passes over the debuginfo.  The first time it
reads "partial symbols".  There are some maint commands ("apropos partial")
to dump this info, that might be helpful to you.

In this first pass, GDB just looks for global symbols -- variables,
functions, and types.  It skips a lot of the debuginfo.

Then when a partial symbol is looked up, its partial symbol table is
expanded to a full symbol table.  In DWARF terms this means reading all
the debuginfo in the CU.

Because there are two scanners, this approach is open to a couple types
of bugs if they disagree.  One is if a symbol appears in a psymtab but
not in a full symtab.  GDB prints an error in that case (maybe
internal_error, I forget).  The other is the reverse, which sounds like
what you've hit.

Tom

Re: "set foo"

[Eli Zaretskii]

> From: Tom Tromey <tromey@redhat.com>
> Cc: brobecker@adacore.com, gdb@sourceware.org
> Date: Mon, 26 Apr 2010 13:45:31 -0600
> 
> I can only say what happens for DWARF debuginfo, I don't know anything
> about the other formats.  (I gather stabs is similar, but I don't know
> details.)

This is on Windows (with MinGW GCC), but the debug info is DWARF2.

> For DWARF, GDB does two passes over the debuginfo.  The first time it
> reads "partial symbols".  There are some maint commands ("apropos partial")
> to dump this info, that might be helpful to you.

"maint info psymbols" indeed does not show "struct Lisp_Symbol", which
was the reason I added "set Fmake_symbol" to .gdbinit.

Re: "set foo"

[Tom Tromey]

>>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:

>> For DWARF, GDB does two passes over the debuginfo.  The first time it
>> reads "partial symbols".  There are some maint commands ("apropos partial")
>> to dump this info, that might be helpful to you.

Eli> "maint info psymbols" indeed does not show "struct Lisp_Symbol", which
Eli> was the reason I added "set Fmake_symbol" to .gdbinit.

One thing you could do is dump the dwarf for the CU holding Fmake_symbol.
Then look for the definition of struct Lisp_Symbol.  Just those DIEs
might be enough to see the problem.

Or you could dump all the dwarf and get it to me somehow.

Tom

Re: "set foo"

[Eli Zaretskii]

> From: Tom Tromey <tromey@redhat.com>
> Cc: brobecker@adacore.com, gdb@sourceware.org
> Date: Mon, 26 Apr 2010 21:11:05 -0600
> 
> >>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> For DWARF, GDB does two passes over the debuginfo.  The first time it
> >> reads "partial symbols".  There are some maint commands ("apropos partial")
> >> to dump this info, that might be helpful to you.
> 
> Eli> "maint info psymbols" indeed does not show "struct Lisp_Symbol", which
> Eli> was the reason I added "set Fmake_symbol" to .gdbinit.
> 
> One thing you could do is dump the dwarf for the CU holding Fmake_symbol.
> Then look for the definition of struct Lisp_Symbol.  Just those DIEs
> might be enough to see the problem.
> 
> Or you could dump all the dwarf and get it to me somehow.

Can GDB dump that?

Re: "set foo"

[Tom Tromey]

>>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:

>> One thing you could do is dump the dwarf for the CU holding Fmake_symbol.
>> Then look for the definition of struct Lisp_Symbol.  Just those DIEs
>> might be enough to see the problem.
>> 
>> Or you could dump all the dwarf and get it to me somehow.

Eli> Can GDB dump that?

No, but you can use objdump.

Tom