New warning in GDB 7.5

New warning in GDB 7.5

[Eli Zaretskii]

When starting GDB 7.5 from the src directory of the Emacs source tree,
GDB now emits warnings that GDB 7.4.1 didn't:

  warning: Expression is not an assignment (and might have no effect)
  warning: Expression is not an assignment (and might have no effect)

These come from the following 2 lines in src/.gdbinit:

  # Force loading of symbols, enough to give us VALBITS etc.
  set main
  # With some compilers, we need this to give us struct Lisp_Symbol etc.:
  set Fmake_symbol

The comments explain why they are needed.

Why was the new warning added? what problem(s) does it solve?

Re: New warning in GDB 7.5

[Joel Brobecker]

> These come from the following 2 lines in src/.gdbinit:
> 
>   # Force loading of symbols, enough to give us VALBITS etc.
>   set main
>   # With some compilers, we need this to give us struct Lisp_Symbol etc.:
>   set Fmake_symbol
> The comments explain why they are needed.

Are these really doing anything? Unless "main" and "Fmake_symbol" were
settings, I think the warning is actually correct: these commands
have no effect.

> Why was the new warning added? what problem(s) does it solve?

The warning was added to catch the situation where the wrong assignment
operator was used. This is very common when you debug a multi-language
application. For instance, when debugging Ada, one might write the
following:

        (gdb) set blabla = 10

But, in Ada mode, the correct assignment operator is ":=", while "="
is the comparison operator. When you keep switching back and forth
between Ada and C code, it's very easy to make that mistake.

-- 
Joel

Re: New warning in GDB 7.5

[Eli Zaretskii]

> Date: Sat, 18 Aug 2012 13:55:43 -0700
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: gdb-patches@sourceware.org
> 
> > These come from the following 2 lines in src/.gdbinit:
> > 
> >   # Force loading of symbols, enough to give us VALBITS etc.
> >   set main
> >   # With some compilers, we need this to give us struct Lisp_Symbol etc.:
> >   set Fmake_symbol
> > The comments explain why they are needed.
> 
> Are these really doing anything?

Yes.  They force GDB to read the symbol table of a couple of object
files, so the symbols from those files are known to GDB.  That is
needed for several commands in the file to work right from the start
of the debugging session.

> Unless "main" and "Fmake_symbol" were settings

No, they are symbols (function names).

> I think the warning is actually correct: these commands have no
> effect.

They have a useful side effect.

> The warning was added to catch the situation where the wrong assignment
> operator was used.

Sigh.  I guess we will have to live with this annoyance, then.

Re: New warning in GDB 7.5

[Mark Kettenis]

> Date: Sun, 19 Aug 2012 00:01:26 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > Date: Sat, 18 Aug 2012 13:55:43 -0700
> > From: Joel Brobecker <brobecker@adacore.com>
> > Cc: gdb-patches@sourceware.org
> > 
> > > These come from the following 2 lines in src/.gdbinit:
> > > 
> > >   # Force loading of symbols, enough to give us VALBITS etc.
> > >   set main
> > >   # With some compilers, we need this to give us struct Lisp_Symbol etc.:
> > >   set Fmake_symbol
> > > The comments explain why they are needed.
> > 
> > Are these really doing anything?
> 
> Yes.  They force GDB to read the symbol table of a couple of object
> files, so the symbols from those files are known to GDB.  That is
> needed for several commands in the file to work right from the start
> of the debugging session.

Sounds like a workaround for a bug in GDB to me.

Re: New warning in GDB 7.5

[Eli Zaretskii]

> Date: Sat, 18 Aug 2012 23:49:21 +0200 (CEST)
> From: Mark Kettenis <mark.kettenis@xs4all.nl>
> CC: brobecker@adacore.com, gdb-patches@sourceware.org
> 
> > > Are these really doing anything?
> > 
> > Yes.  They force GDB to read the symbol table of a couple of object
> > files, so the symbols from those files are known to GDB.  That is
> > needed for several commands in the file to work right from the start
> > of the debugging session.
> 
> Sounds like a workaround for a bug in GDB to me.

I always thought lazy loading of symbols was a feature, not a bug.

Re: New warning in GDB 7.5

[Joel Brobecker]

> I always thought lazy loading of symbols was a feature, not a bug.

Shouldn't the commands work regardless of whether symbols have been
fully loaded or not, though? Lazy psymtab-to-symtab conversion should
be transparent to the user.

-- 
Joel

Re: New warning in GDB 7.5

[Eli Zaretskii]

> Date: Sat, 18 Aug 2012 21:36:52 -0700
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: Mark Kettenis <mark.kettenis@xs4all.nl>, gdb-patches@sourceware.org
> 
> > I always thought lazy loading of symbols was a feature, not a bug.
> 
> Shouldn't the commands work regardless of whether symbols have been
> fully loaded or not, though?

That would be nice, but I don't know of any way to do that.  If you
look at Emacs's src/.gdbinit, you will see at its end that it needs
some symbols right at startup, when the program was not yet started.
If there are commands to control which symbols are loaded when GDB
starts, they might help.  Otherwise, I will replace those two "set"
commands with something like

  set $dummy = main + 8

which does the job, and suppresses the warning.

> Lazy psymtab-to-symtab conversion should be transparent to the user.

But what is its trigger?  And will this transparent conversion kick in
when .gdbinit does the following?

  # People get bothered when they see messages about non-existent functions...
  xgetptr globals.f_Vsystem_type
  # $ptr is NULL in temacs
  if ($ptr != 0)
    set $tem = (struct Lisp_Symbol *) $ptr
    xgetptr $tem->name
    set $tem = (struct Lisp_String *) $ptr
    set $tem = (char *) $tem->data

    # Don't let abort actually run, as it will make stdio stop working and
    # therefore the `pr' command above as well.
    if $tem[0] == 'w' && $tem[1] == 'i' && $tem[2] == 'n' && $tem[3] == 'd'
      # The windows-nt build replaces abort with its own function.
      break w32_abort
    else
      break abort
    end
  end

Here, GDB needs to know what is Lisp_String and Lisp_Symbol, and also
the various bit masks used by xgetptr (defined earlier in the file).

Re: New warning in GDB 7.5

[Joel Brobecker]

> That would be nice, but I don't know of any way to do that.  If you
> look at Emacs's src/.gdbinit, you will see at its end that it needs
> some symbols right at startup, when the program was not yet started.
[...]
> But what is its trigger?

It's usually the first reference to the symbol. Basically, GDB does
a quick-load of the debug info into partial symtabs (containing
partial symbols), and upgrades it to full symtab/symbols when first
referenced.

> And will this transparent conversion kick in
> when .gdbinit does the following?

Maybe it does not ATM, but I don't see why it shouldn't. If it
does not, I agree with Mark that this is suspicious.

-- 
Joel

Re: New warning in GDB 7.5

[Eli Zaretskii]

> Date: Sun, 19 Aug 2012 11:06:47 -0700
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: mark.kettenis@xs4all.nl, gdb-patches@sourceware.org
> 
> Maybe it does not ATM, but I don't see why it shouldn't. If it
> does not, I agree with Mark that this is suspicious.

I'd welcome pointers to where to look in order to debug this, then.

Re: New warning in GDB 7.5

[Joel Brobecker]

> I'd welcome pointers to where to look in order to debug this, then.

I didn't really completely understand what the problem was, so I do not
think I am getting the whole picture. But I'd probably start from the
first error message you get, and find your way back.

-- 
Joel

Re: New warning in GDB 7.5

[Mark Kettenis]

> Date: Sun, 19 Aug 2012 11:06:47 -0700
> From: Joel Brobecker <brobecker@adacore.com>
> 
> > And will this transparent conversion kick in
> > when .gdbinit does the following?
> 
> Maybe it does not ATM, but I don't see why it shouldn't. If it
> does not, I agree with Mark that this is suspicious.

Unfortunately the partial symbol table only contains information about
symbols.  In particular it doesn't contain type info.  So the
transparent conversion doesn't kick in if your .gdbinit only
references types.

Re: New warning in GDB 7.5

[Eli Zaretskii]

> Date: Sun, 19 Aug 2012 20:32:36 +0200 (CEST)
> From: Mark Kettenis <mark.kettenis@xs4all.nl>
> CC: eliz@gnu.org, gdb-patches@sourceware.org
> 
> Unfortunately the partial symbol table only contains information about
> symbols.  In particular it doesn't contain type info.  So the
> transparent conversion doesn't kick in if your .gdbinit only
> references types.

I'm not sure I understand.  Can you give an example of "only
referencing types" as opposed to the other kind of references?

Thanks.

Re: New warning in GDB 7.5

[Mark Kettenis]

> Date: Sun, 19 Aug 2012 21:59:16 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > Date: Sun, 19 Aug 2012 20:32:36 +0200 (CEST)
> > From: Mark Kettenis <mark.kettenis@xs4all.nl>
> > CC: eliz@gnu.org, gdb-patches@sourceware.org
> > 
> > Unfortunately the partial symbol table only contains information about
> > symbols.  In particular it doesn't contain type info.  So the
> > transparent conversion doesn't kick in if your .gdbinit only
> > references types.
> 
> I'm not sure I understand.  Can you give an example of "only
> referencing types" as opposed to the other kind of references?

From the example you gave earlier:

    set $tem = (struct Lisp_Symbol *) $ptr

probably won't trigger a full symbol read since "struct Lisp_Symbol"
is a type and not a function or variable.

Re: New warning in GDB 7.5

[Eli Zaretskii]

> Date: Sun, 19 Aug 2012 21:10:49 +0200 (CEST)
> From: Mark Kettenis <mark.kettenis@xs4all.nl>
> CC: brobecker@adacore.com, gdb-patches@sourceware.org
> 
> From the example you gave earlier:
> 
>     set $tem = (struct Lisp_Symbol *) $ptr
> 
> probably won't trigger a full symbol read since "struct Lisp_Symbol"
> is a type and not a function or variable.

Thanks.

Re: New warning in GDB 7.5

[Jan Kratochvil]

On Sun, 19 Aug 2012 21:10:49 +0200, Mark Kettenis wrote:
>     set $tem = (struct Lisp_Symbol *) $ptr
> 
> probably won't trigger a full symbol read since "struct Lisp_Symbol"
> is a type and not a function or variable.

It will, because GDB generates symbols for each type.  See for example:
process_structure_scope -> new_symbol_full <DW_TAG_structure_type> ->
-> add_symbol_to_list

It should work without any stub 'set' commands, if it does not one should have
a reproducer (one can download Emacs but a minimal reproducer would be
better).


Regards,
Jan


struct s { int i; } v;
gdb -ex r --args ./gdb ./63.o 
Reading symbols from /home/jkratoch/redhat/gdb-clean/gdb/63.o...done.
(gdb) maintenance info psymtabs 
{ objfile /home/jkratoch/redhat/gdb-clean/gdb/63.o ((struct objfile *) 0x2224c80)
  { psymtab 63.c ((struct partial_symtab *) 0x2218dc0)
    readin no
    fullname (null)
    text addresses 0x0 -- 0x0
    psymtabs_addrmap_supported yes
    globals (* (struct partial_symbol **) 0x221a780 @ 1)
    statics (* (struct partial_symbol **) 0x222fe50 @ 2)
    dependencies (none)
  }
}
(gdb) maintenance info symtabs 
(gdb) 
Program received signal SIGINT, Interrupt.
0x00007ffff638dd30 in __poll_nocancel () at ../sysdeps/unix/syscall-template.S:81
81	T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)
# global symbol
(gdb) p *(* (struct partial_symbol **) 0x221a780 @ 1)[0]
$3 = {ginfo = {name = 0x2218d5a "v", value = {ivalue = 0, block = 0x0, bytes = 0x0, address = 0, chain = 0x0}, language_specific = {mangled_lang = {
        demangled_name = 0x0}, cplus_specific = 0x0}, language = language_c, section = 0, obj_section = 0x0}, domain = VAR_DOMAIN, aclass = LOC_STATIC}
# static symbol
(gdb) p *(* (struct partial_symbol **) 0x222fe50 @ 2)[0]
$5 = {ginfo = {name = 0x2218d55 "int", value = {ivalue = 0, block = 0x0, bytes = 0x0, address = 0, chain = 0x0}, language_specific = {mangled_lang = {
        demangled_name = 0x0}, cplus_specific = 0x0}, language = language_c, section = 0, obj_section = 0x0}, domain = VAR_DOMAIN, aclass = LOC_TYPEDEF}
# static symbol
(gdb) p *(* (struct partial_symbol **) 0x222fe50 @ 2)[1]
$6 = {ginfo = {name = 0x2218d3e "s", value = {ivalue = 0, block = 0x0, bytes = 0x0, address = 0, chain = 0x0}, language_specific = {mangled_lang = {
        demangled_name = 0x0}, cplus_specific = 0x0}, language = language_c, section = 0, obj_section = 0x0}, domain = STRUCT_DOMAIN, aclass = LOC_TYPEDEF}
(gdb) c
Continuing.

(gdb) p (struct s *) 0
$1 = (struct s *) 0x0
(gdb) maintenance info symtabs 
{ objfile /home/jkratoch/redhat/gdb-clean/gdb/63.o ((struct objfile *) 0x2224c80)
	{ symtab 63.c ((struct symtab *) 0x2219790)
	  dirname /home/jkratoch/redhat/gdb-clean/gdb
	  fullname (null)
	  blockvector ((struct blockvector *) 0x2219770) (primary)
	  linetable ((struct linetable *) 0x0)
	  debugformat DWARF 2
	}
}

Re: New warning in GDB 7.5

[Eli Zaretskii]

> Date: Mon, 20 Aug 2012 16:24:17 +0200
> From: Jan Kratochvil <jan.kratochvil@redhat.com>
> Cc: eliz@gnu.org, brobecker@adacore.com, gdb-patches@sourceware.org
> 
> On Sun, 19 Aug 2012 21:10:49 +0200, Mark Kettenis wrote:
> >     set $tem = (struct Lisp_Symbol *) $ptr
> > 
> > probably won't trigger a full symbol read since "struct Lisp_Symbol"
> > is a type and not a function or variable.
> 
> It will, because GDB generates symbols for each type.  See for example:
> process_structure_scope -> new_symbol_full <DW_TAG_structure_type> ->
> -> add_symbol_to_list

If it relies on DW_TAG_structure_type, it needs DWARF, perhaps even
newer than DWARF-2, doesn't it?  Emacs debugging shouldn't depend on
that.

Re: New warning in GDB 7.5

[Jan Kratochvil]

On Mon, 20 Aug 2012 18:32:38 +0200, Eli Zaretskii wrote:
> > It will, because GDB generates symbols for each type.  See for example:
> > process_structure_scope -> new_symbol_full <DW_TAG_structure_type> ->
> > -> add_symbol_to_list
> 
> If it relies on DW_TAG_structure_type, it needs DWARF, perhaps even
> newer than DWARF-2, doesn't it?

I have verified it for DWARF (GDB no longer supports version 1 and any version 2
upwards behaves the same in this simple case).  I do not know if it works for
STABS and other formats but any non-DWARF format has poor debugging anyway and
there is normally no reason to use anything else than DWARF.


> Emacs debugging shouldn't depend on that.

We can conclude then it may be a workaround of GDB bugs in non-DWARF formats
support (maybe, maybe not).  I do not find meaningful to actively support
non-DWARF debugging, it is just best-effort.


Thanks,
Jan

Re: New warning in GDB 7.5

[Eli Zaretskii]

> Date: Mon, 20 Aug 2012 19:06:55 +0200
> From: Jan Kratochvil <jan.kratochvil@redhat.com>
> Cc: mark.kettenis@xs4all.nl, brobecker@adacore.com, gdb-patches@sourceware.org
> 
> We can conclude then it may be a workaround of GDB bugs in non-DWARF formats
> support (maybe, maybe not).  I do not find meaningful to actively support
> non-DWARF debugging, it is just best-effort.

Fair enough.  I replaced those commands with

  set $dummy = main + 8

and the warnings went away.

Thanks.

Re: New warning in GDB 7.5

[Tom Tromey]

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

Eli> Here, GDB needs to know what is Lisp_String and Lisp_Symbol, and also
Eli> the various bit masks used by xgetptr (defined earlier in the file).

I think it will all just work.
And, Mark is right, if it doesn't work, it is a gdb bug.

It seems to work ok for me.  For example:

    barimba. gdb -nx ./src/emacs 
    [...]
    (gdb) p (struct Lisp_Symbol *) 0
    $1 = (struct Lisp_Symbol *) 0x0

It works similarly with Lisp_String.

Could you try commenting out the "set" lines in your .gdbinit and then
see if something doesn't work?

Tom

Re: New warning in GDB 7.5

[Eli Zaretskii]

> From: Tom Tromey <tromey@redhat.com>
> Cc: Joel Brobecker <brobecker@adacore.com>, mark.kettenis@xs4all.nl,
>         gdb-patches@sourceware.org
> Date: Mon, 20 Aug 2012 09:01:08 -0600
> 
> Could you try commenting out the "set" lines in your .gdbinit and then
> see if something doesn't work?

If you say that it should work even without DWARF, I will try, when I
have time.  Thanks.

Re: New warning in GDB 7.5

[Tom Tromey]

Eli> If you say that it should work even without DWARF, I will try, when I
Eli> have time.  Thanks.

Sorry, I know basically nothing about non-DWARF debuginfo.
The general design of gdb is such that, IMO, it could work; but whether
it actually does depends on the debuginfo reader.

Tom

Re: New warning in GDB 7.5

[Tom Tromey]

Eli> If you say that it should work even without DWARF, I will try, when I
Eli> have time.  Thanks.

Tom> Sorry, I know basically nothing about non-DWARF debuginfo.
Tom> The general design of gdb is such that, IMO, it could work; but whether
Tom> it actually does depends on the debuginfo reader.

I rebuilt emacs with -gstabs and my test worked fine.
I didn't try anything else.

Tom

Re: New warning in GDB 7.5

[Eli Zaretskii]

> From: Tom Tromey <tromey@redhat.com>
> Cc: brobecker@adacore.com, mark.kettenis@xs4all.nl, gdb-patches@sourceware.org
> Date: Mon, 20 Aug 2012 12:03:06 -0600
> 
> I rebuilt emacs with -gstabs and my test worked fine.
> I didn't try anything else.

The problem was described here:

  http://lists.gnu.org/archive/html/emacs-devel/2010-04/msg01124.html

I can still reproduce it, even with GDB 7.5, with a binary of Emacs
24.0.90 (an early pretest of v24.1), which was compiled with GCC 3.4.2
on Windows with "-gdwarf-2 -g3".  If I remove this line from .gdbinit:

 set Fmake_symbol

I get this error:

  D:\gnu\emacs-24.x\emacs-24.0.90\src>gdb ./oo-spd/i386/emacs.exe
  GNU gdb (GDB) 7.5
  Copyright (C) 2012 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
  This is free software: you are free to change and redistribute it.
  There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
  and "show warranty" for details.
  This GDB was configured as "i686-pc-mingw32".
  For bug reporting instructions, please see:
  <http://www.gnu.org/software/gdb/bugs/>...
  Reading symbols from D:\gnu\emacs-24.x\emacs-24.0.90\src\oo-spd\i386\emacs.exe...done.
  warning: Expression is not an assignment (and might have no effect)
  SIGINT is used by the debugger.
  Are you sure you want to change it? (y or n) [answered Y; input not from terminal]
  Environment variable "DISPLAY" not defined.
  Environment variable "TERM" not defined.
  .gdbinit:1333: Error in sourced command file:  <<<<<<<<<<<<<<<<<<<
  No struct type named Lisp_Symbol.              <<<<<<<<<<<<<<<<<<<

This doesn't happen with the latest Emacs trunk (nor with several
other binaries I have that I tried), compiled with the same version of
GCC.  So I guess this is some subtle problem that is sensitive to the
arrangement of symbols in the debug info or something.

Re: New warning in GDB 7.5

[Tom Tromey]

Eli> I can still reproduce it, even with GDB 7.5, with a binary of Emacs
Eli> 24.0.90 (an early pretest of v24.1), which was compiled with GCC
Eli> 3.4.2 on Windows with "-gdwarf-2 -g3".

That's a very old version of gcc.
So it could also be a gcc bug, fixed sometime in the last 8 years.
You'd have to look through the debuginfo to be sure.

Tom