Displaying structure members named like C keywords.

[Emilio Lopes]

I'm having trouble trying to display structure members with names like
C keywords. GDB refuses to display the member called `complex' in
this case.

Here is the structure:

(gdb) p g_global_paramv[37].info
$27 = {
complex = {
paramc = 20,
paramv = 0xd14f4 <_sys_opt>
},
cmd = {
cmd_fct = 0x14,
wrap = 0xd14f4 <_sys_opt>
},
alias = {
type = 20,
link = 0xd14f4 <_sys_opt>
}
}

Printing other members is no problem:

(gdb) p g_global_paramv[37].info.cmd
$28 = {
cmd_fct = 0x14,
wrap = 0xd14f4 <_sys_opt>
}
(gdb) p g_global_paramv[37].info.alias
$29 = {
type = 20,
link = 0xd14f4 <_sys_opt>
}

But trying to print the member `complex' results in an error:

(gdb) p g_global_paramv[37].info.complex
A syntax error in expression, near `complex'.

Note that the error message for non-existing members is different
depending if their names are C keywords (`long' and `int' => "syntax
error") or not (`foobar', `xyz' => "no member named ...").

(gdb) p g_global_paramv[37].info.foobar
There is no member named foobar.
(gdb) p g_global_paramv[37].info.long
A syntax error in expression, near `long'.
(gdb) p g_global_paramv[37].info.int
A syntax error in expression, near `int'.
(gdb) p g_global_paramv[37].info.xyz
There is no member named xyz.
(gdb)

This happens using gdb-7.8 configured as following:

(gdb) show version
GNU gdb (GDB) 7.8
Copyright (C) 2014 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 "--host=x86_64-unknown-linux-gnu
--target=arm-cortexa8-linux-gnueabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb) show configuration
This GDB was configured as follows:
configure --host=x86_64-unknown-linux-gnu
--target=arm-cortexa8-linux-gnueabi
--with-auto-load-dir=$debugdir:$datadir/auto-load
--with-auto-load-safe-path=$debugdir:$datadir/auto-load
--with-expat
--with-gdb-datadir=/usr/local/share/gdb (relocatable)
--with-jit-reader-dir=/usr/local/lib/gdb (relocatable)
--without-libunwind-ia64
--with-lzma
--with-python=/usr
--without-guile
--with-separate-debug-dir=/usr/local/lib/debug (relocatable)
--with-zlib
--without-babeltrace

("Relocatable" means the directory can be moved with the GDB installation
tree, and GDB will still find it.)

The code was compiled using:

$ arm-cortexa8-linux-gnueabi-gcc --version
arm-cortexa8-linux-gnueabi-gcc (OSELAS.Toolchain-2012.12.1
linaro-4.7-2012.11) 4.7.3 20121106 (prerelease)
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

GDB itself was compiled with:

$ gcc --version
gcc (Debian 4.9.0-7) 4.9.0
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Thank you very much!

Emílio

[Sergio Durigan Junior]

On Thursday, August 21 2014, Emilio Lopes wrote:

> I'm having trouble trying to display structure members with names like
> C keywords. GDB refuses to display the member called `complex' in
> this case.

Hello Emilio,

> Here is the structure:
>
> (gdb) p g_global_paramv[37].info
> $27 = {
> complex = {
> paramc = 20,
> paramv = 0xd14f4 <_sys_opt>
> },
> cmd = {
> cmd_fct = 0x14,
> wrap = 0xd14f4 <_sys_opt>
> },
> alias = {
> type = 20,
> link = 0xd14f4 <_sys_opt>
> }
> }

I could not reproduce the problem here. Would you mind providing the
structure declaration, or at least a reproducer?

Thanks,

--
Sergio
GPG key ID: 0x65FC5E36
Please send encrypted e-mail if possible
http://sergiodj.net/

[Emilio Lopes]

> I could not reproduce the problem here. Would you mind providing the
> structure declaration, or at least a reproducer?

Hello Sergio,

thank you very much for your prompt answer!

Here is the declaration of the structure:

typedef struct param_t {
const char* name;
type_t type;
short not_available : 1;
short rlevel : 4;
short wlevel : 4;
union {
struct {
void* get_fct;
void* set_fct;
void* gsv_fct;
int32_t polling_default;
int32_t polling_min;
} natural;
struct {
unsigned short paramc;
struct param_t* paramv;
} complex;
struct {
void (*cmd_fct)();
void (*wrap)(void (*cmd_fct)(), p_id cmd, const variant_t*
argv, size_t argc, variant_t* res);
} cmd;
struct {
type_t type;
struct param_t *link;
} alias;
} info;
struct param_t* parent;
void* user_data;
} param_t;

extern param_t* const g_global_paramv;

Regards

Emílio

[Sergio Durigan Junior]

On Thursday, August 21 2014, Emilio Lopes wrote:

>> I could not reproduce the problem here. Would you mind providing the
>> structure declaration, or at least a reproducer?
>
> Hello Sergio,
>
> thank you very much for your prompt answer!
>
> Here is the declaration of the structure:

Thanks, Emilio.

I am still not able to reproduce it here, using git HEAD or grabbing
7.8's source. Would it be possible for you to come up with a simpler
reproducer and send it to this list? I am guessing there is something
else in your code that might be triggering this.

[Emilio Lopes]

Hi Sergio,

thank you for taking a look at this issue.

> Would it be possible for you to come up with a simpler reproducer
> and send it to this list? I am guessing there is something else in
> your code that might be triggering this.

I was hoping for this to be something simple... Oh, well.

As you can imagine this is a somewhat larger codebase, with lots of
automatically generated code from XML files, using those structures.

But look at the transcript of this debugging session:

$ arm-cortexa8-linux-gnueabi-gdb
build/master-device-control/master_device_control

GNU gdb (GDB) 7.8
Copyright (C) 2014 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 "--host=x86_64-unknown-linux-gnu
--target=arm-cortexa8-linux-gnueabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".

Type "apropos word" to search for commands related to "word"...
Reading symbols from
build/master-device-control/master_device_control...done.
(gdb) target remote 192.168.51.84:6666
Remote debugging using 192.168.51.84:6666
warning: Unable to find dynamic linker breakpoint function.
GDB will be unable to debug shared library initializers
and track explicitly loaded dynamic code.
Cannot access memory at address 0x0
0xb6fbadf0 in ?? ()
(gdb) b hal-cmd-proxy.c:16
Breakpoint 1 at 0x79ae0: file
/home/lopes/projects/hal/firmware-cmd-manager/master-device-control/hal-cmd-proxy/hal-cmd-proxy.c,
line 16.
(gdb) c
Continuing.
warning: Could not load shared library symbols for 7 libraries,
e.g. /lib/libpthread.so.0.
Use the "info sharedlibrary" command to see the complete listing.
Do you need "set solib-search-path" or "set sysroot"?
[New Thread 1562]
[Switching to Thread 1562]

Breakpoint 1, hal_cmd_proxy () at
/home/lopes/projects/hal/firmware-cmd-manager/master-device-control/hal-cmd-proxy/hal-cmd-proxy.c:16
16
set_param_not_available(C_HAL_SLAVE_OPTMIN_START_OPTIMIZATION,
enabled);
(gdb) info macro P_SLAVE_CMDS_OPTIONS_HAL_OPTMIN_ENABLED
Defined at /home/lopes/projects/hal/firmware-cmd-manager/build/master-device-control/d-param-defs.h:8151
included at
/home/lopes/projects/hal/firmware-cmd-manager/master-device-control/hal-cmd-proxy/hal-cmd-proxy.c:5
#define P_SLAVE_CMDS_OPTIONS_HAL_OPTMIN_ENABLED
(&g_global_paramv[31].info.complex.paramv[29].info.complex.paramv[0].info.complex.paramv[1].info.complex.paramv[0])
(gdb) p P_SLAVE_CMDS_OPTIONS_HAL_OPTMIN_ENABLED
$1 = (struct param_t *) 0x10db9c <_slave_cmds_options_hal_optmin>
(gdb) set sysroot ~/projects/hal/system/platform-tam3517/root-debug
Reading symbols from
/home/lopes/projects/hal/system/platform-tam3517/root-debug/lib/libpthread.so.0...done.
Loaded symbols for
/home/lopes/projects/hal/system/platform-tam3517/root-debug/lib/libpthread.so.0
Reading symbols from
/home/lopes/projects/hal/system/platform-tam3517/root-debug/lib/librt.so.1...done.
Loaded symbols for
/home/lopes/projects/hal/system/platform-tam3517/root-debug/lib/librt.so.1
Reading symbols from
/home/lopes/projects/hal/system/platform-tam3517/root-debug/lib/libstdc++.so.6...done.
Loaded symbols for
/home/lopes/projects/hal/system/platform-tam3517/root-debug/lib/libstdc++.so.6
Reading symbols from
/home/lopes/projects/hal/system/platform-tam3517/root-debug/lib/libm.so.6...done.
Loaded symbols for
/home/lopes/projects/hal/system/platform-tam3517/root-debug/lib/libm.so.6
Reading symbols from
/home/lopes/projects/hal/system/platform-tam3517/root-debug/lib/libgcc_s.so.1...done.
Loaded symbols for
/home/lopes/projects/hal/system/platform-tam3517/root-debug/lib/libgcc_s.so.1
Reading symbols from
/home/lopes/projects/hal/system/platform-tam3517/root-debug/lib/libc.so.6...done.
Loaded symbols for
/home/lopes/projects/hal/system/platform-tam3517/root-debug/lib/libc.so.6
Reading symbols from
/home/lopes/projects/hal/system/platform-tam3517/root-debug/lib/ld-linux.so.3...done.
Loaded symbols for
/home/lopes/projects/hal/system/platform-tam3517/root-debug/lib/ld-linux.so.3
(gdb) p P_SLAVE_CMDS_OPTIONS_HAL_OPTMIN_ENABLED

A syntax error in expression, near

`complex.paramv[29].info.complex.paramv[0].info.complex.paramv[1].info.complex.paramv[0])'.
(gdb) set sysroot ''
warning: Unable to find dynamic linker breakpoint function.
GDB will be unable to debug shared library initializers
and track explicitly loaded dynamic code.
(gdb) p P_SLAVE_CMDS_OPTIONS_HAL_OPTMIN_ENABLED
$2 = (struct param_t *) 0x10db9c <_slave_cmds_options_hal_optmin>
(gdb)

Problems come and go as I set/unset `sysroot'!!! (I'm debugging code
running on an ARM evaluation board remotely.)

I can live without setting `sysroot', but would be glad to help
finding the cause for this issue.

Can you give me a hint on what to look for from here?

Regards

Emílio

[Sergio Durigan Junior]

On Friday, August 22 2014, Emilio Lopes wrote:

>> Would it be possible for you to come up with a simpler reproducer
>> and send it to this list? I am guessing there is something else in
>> your code that might be triggering this.
>
> I was hoping for this to be something simple... Oh, well.

Yeah, sometimes issues are not so simple...

> As you can imagine this is a somewhat larger codebase, with lots of
> automatically generated code from XML files, using those structures.

Sure, that is also why I asked for a simpler reproducer :-).

Hm, OK, I'm thinking about some issue with symbols here (visibility
maybe). I made lots of attempts here to reproduce it based on what you
posted, but I still cannot see this behavior using GDB from git HEAD.

If you cannot give more instructions on how to reproduce this, then I
have to ask you to file a bug against GDB on
<https://sourceware.org/bugzilla>, please.

> Can you give me a hint on what to look for from here?

There are a few debug triggers that you can enable on GDB. Maybe 'set
debug expression 1' could help. Also, you can use 'maintenance print
symbols <filename>' to print all the symbols; this could help analyzing
if 'complex' is being hidden by some other library. Feel free to post
those things here.

Cheers,

[Emilio Lopes]

Hello Sergio,

I was able to reproduce this issue on the host (x86_64 GNU/Linux)!

Here we go:

$ cat gdb-reproducer.c
#include <iostream>

using std::cout;

typedef struct {
int rlevel;
int complex;
} param_t;

int main(int argc, char *argv[]) {
param_t foo;

foo.rlevel = 4;
foo.complex= foo.rlevel + 11;

cout << "foo.complex: " << foo.complex << "\n";

return(0);
}

$ g++ -Wall -ggdb3 gdb-reproducer.c && ./a.out
foo.complex: 15

$ gdb a.out
GNU gdb (Debian 7.7.1+dfsg-3) 7.7.1

Copyright (C) 2014 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 "x86_64-linux-gnu".

Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...

Reading symbols from a.out...done.
(gdb) b main
Breakpoint 1 at 0x4007c6: file gdb-reproducer.c, line 13.
(gdb) r
Starting program: /home/lopes/projects/c/a.out

Breakpoint 1, main (argc=1, argv=0x7fffffffe958) at gdb-reproducer.c:13
13 foo.rlevel = 4;
(gdb) n
14 foo.complex= foo.rlevel + 11;
(gdb) n
16 cout << "foo.complex: " << foo.complex << "\n";
(gdb) p foo
$1 = {rlevel = 4, complex = 15}
(gdb) ptype foo
type = struct param_t {
int rlevel;
int complex;
}
(gdb) p foo.complex
A syntax error in expression, near `'.
(gdb) info shared
From To Syms Read Shared Object Library
0x00007ffff7ddcae0 0x00007ffff7df5170 Yes
/lib64/ld-linux-x86-64.so.2
No linux-vdso.so.1
0x00007ffff7b2c8e0 0x00007ffff7b9480a Yes
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
0x00007ffff77d5580 0x00007ffff7840de6 Yes
/lib/x86_64-linux-gnu/libm.so.6
0x00007ffff75bcab0 0x00007ffff75cc995 Yes
/lib/x86_64-linux-gnu/libgcc_s.so.1
0x00007ffff72304a0 0x00007ffff735a613 Yes
/lib/x86_64-linux-gnu/libc.so.6
(gdb) noshared
(gdb) p foo.complex
$2 = 15
(gdb) p foo
$3 = {rlevel = 4, complex = 15}
(gdb) p foo.complex
$4 = 15
(gdb) shared libstdc.*
Reading symbols from
/usr/lib/x86_64-linux-gnu/libstdc++.so.6...Reading symbols from
/usr/lib/debug//usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.20...done.
done.
Loaded symbols for /usr/lib/x86_64-linux-gnu/libstdc++.so.6
(gdb) p foo.complex
A syntax error in expression, near `'.
(gdb) p foo
$5 = {rlevel = 4, complex = 15}
(gdb) ptype foo
type = struct param_t {
int rlevel;
int complex;
}

It seems that something in the debug info of libstdc++ is causing the problem.

Some info about the system I'm using:

$ uname -a
Linux lopes 3.14-1-amd64 #1 SMP Debian 3.14.12-1 (2014-07-11)
x86_64 GNU/Linux
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian
4.9.1-4' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.9 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.9
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--enable-gnu-unique-object --disable-vtable-verify --enable-plugin
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre
--enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64
--with-arch-directory=amd64
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc
--enable-multiarch --with-arch-32=i586 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.9.1 (Debian 4.9.1-4)
$ dpkg -l | grep -F 'libstdc++'
ii libstdc++-4.9-dev:amd64 4.9.1-4 amd64 GNU
Standard C++ Library v3 (development files)
ii libstdc++6:amd64 4.9.1-4 amd64 GNU
Standard C++ Library v3
ii libstdc++6-4.9-dbg:amd6 4.9.1-4 amd64 GNU
Standard C++ Library v3 (debugging files)
$ dpkg -l | grep -F 'gcc'
ii gcc 4:4.9.0-4 amd64 GNU C compiler
ii gcc-4.7-base:amd64 4.7.4-2 amd64 GCC,
the GNU Compiler Collection (base package)
ii gcc-4.8 4.8.3-7 amd64 GNU C compiler
ii gcc-4.8-base:amd64 4.8.3-7 amd64 GCC,
the GNU Compiler Collection (base package)
ii gcc-4.9 4.9.1-4 amd64 GNU C compiler
ii gcc-4.9-base:amd64 4.9.1-4 amd64 GCC,
the GNU Compiler Collection (base package)
ii libgcc-4.8-dev:amd64 4.8.3-7 amd64 GCC
support library (development files)
ii libgcc-4.9-dev:amd64 4.9.1-4 amd64 GCC
support library (development files)
ii libgcc1:amd64 1:4.9.1-4 amd64 GCC
support library
ii libgcc1-dbg:amd64 1:4.9.1-4 amd64 GCC
support library (debug symbols)
ii linux-compiler-gcc-4.8- 3.14.15-2 amd64
Compiler for Linux on x86 (meta-package)

Please let me know if you can reproduce this. I've also seen this
error when using GDB 7.8 and IIRC 7.6.

[Sergio Durigan Junior]

On Tuesday, August 26 2014, Emilio Lopes wrote:

> Hello Sergio,
>
> I was able to reproduce this issue on the host (x86_64 GNU/Linux)!
>

[...]

> It seems that something in the debug info of libstdc++ is causing the problem.

Aha, yeah, I was indeed suspecting that libstdc++'s debuginfo would be
the cause. I managed to reproduce it here. I still need to investigate
this in order to identify what's going on, and I think I'll be able to
do this only on the weekend. Meanwhile, I strongly advise you to file a
bug against GDB on <https://sourceware.org/bugzilla>. Also, please be
aware that this list (<bug...@gnu.org>) is not used by most of GDB
developers anymore; there's just a few of us hanging around here.
Instead, the official mailing list for users is <g...@sourceware.org>.

I will let you know if I make any progress about this issue.

[Emilio Lopes]

2014-08-26 21:30 GMT+02:00 Sergio Durigan Junior <serg...@sergiodj.net>:
> Aha, yeah, I was indeed suspecting that libstdc++'s debuginfo would be

> the cause. I managed to reproduce it here. [...]

Hello Sergio,

that's indeed good news, thank you very much for your efforts!

> Meanwhile, I strongly advise you to file a bug against GDB on
> <https://sourceware.org/bugzilla>. Also, please be aware that this
> list (<bug...@gnu.org>) is not used by most of GDB developers
> anymore; there's just a few of us hanging around here. Instead,
> the official mailing list for users is <g...@sourceware.org>.

Yes, I'm aware of this. Nevertheless the fact that I need to create
yet another account kept me from using the bugzilla interface.
It seems to me like an unnecessary barrier for an occasional bug reporter.

All the best!

Emílio

[Sergio Durigan Junior]

On Wednesday, August 27 2014, Emilio Lopes wrote:

> Yes, I'm aware of this. Nevertheless the fact that I need to create
> yet another account kept me from using the bugzilla interface.
> It seems to me like an unnecessary barrier for an occasional bug reporter.

Yeah, I understand and agree with you :-). If you wish, I can create
the bug for you, and put you on the Cc list. How does that sound?

[Emilio Lopes]

2014-08-27 15:45 GMT+02:00 Sergio Durigan Junior <serg...@sergiodj.net>:
> Yeah, I understand and agree with you :-). If you wish, I can create
> the bug for you, and put you on the Cc list. How does that sound?

That's very nice from you, thank you very much!

Emílio