GDB can not show the type info of wxCommandEvent

[ollydbg]

Hi, when debugging a wx project(e.g. a wx project create by wxwidgets wizard in C::B), you can simply set a breakpoint in a event handler, for example:

Code

void NumCheckFrame::OnAbout(wxCommandEvent& event)
{
    wxString msg = wxbuildinfo(long_f);  //Set a breakpoint here
    wxMessageBox(msg, _("Welcome to..."));
}

When GDB hit the BP, you try to see the "event" value, but you get:

Code

> p event

[debug]> p event
[debug]$1 = (wxCommandEvent &) @0x22fb34: <incomplete type>
[debug]>>>>>>cb_gdb:

$1 = (wxCommandEvent &) @0x22fb34: <incomplete type>

You see "incomplete type". This happens also when you type: "ptype wxCommandEvent".

I use GDB CVS head mingw build.
        gcc 4.6.3 + wx2.8.12release build lib ----> have this issue
        gcc 4.7.1 + wx2.8.12release build lib ----> have this issue
But if you link to wx2.8.12debug build lib, there is no such issue.

Do you have the same result under Linux?
Is it the expect behavior, I see a related post several years ago : Debug watches problem (Incomplete type)

Thanks.

[oBFusCATed]

Yes, same on linux. I think there is a bug report for GDB, but I'm not sure.

[ollydbg]

Hi, Obf, thanks for the report from Linux.
I just check the exe file (link to release-wx-library) build by using "objdump -W xxx.exe >>a.txt", I found one entry:

Code

 <1><32811>: Abbrev Number: 130 (DW_TAG_class_type)
    <32813>   DW_AT_name        : (indirect string, offset: 0xa54): wxCommandEvent	
    <32817>   DW_AT_declaration : 1	
    <32818>   DW_AT_sibling     : <0x32865>	

Look, there is no DW_AT_decl_file and DW_AT_decl_line information.

If I check the exe file link to a debug-wx-library, I see a similar entry DW_TAG_class_type about wxCommandEvent without any DW_AT_decl_file and DW_AT_decl_line info.

So, I believe the line and file info was saved in wxmsw28ud_gcc_custom.dll, which was 180M in my computer, running objdump -W on this dll file will produce a 1.6G text file (in-fact I stop this command by CTRL+C, because I think there is no text editor can read such big text file), anyway, as "ptype wxCommandEvent" works fine in this case, so the DW_AT_decl_file and DW_AT_decl_line of wxCommandEvent should in this big dll.

I'm not sure why GCC does not put the DW_AT_decl_file and DW_AT_decl_line of wxCommandEvent in the exe file, maybe, it just optimized the output size.... Maybe, its a GCC bug.

[ollydbg]

I'm not sure why GCC does not put the DW_AT_decl_file and DW_AT_decl_line of wxCommandEvent in the exe file, maybe, it just optimized the output size.... Maybe, its a GCC bug.

Aha, It's not a GCC bug, but it's an optimization of GCC, I found that there is an debug option:

-femit-class-debug-always
    Instead of emitting debugging information for a C++ class in only one object file, emit it in all object files using the class. This option should be used only with debuggers that are unable to handle the way GCC normally emits debugging information for classes because using this option increases the size of debugging information by as much as a factor of two.

See: http://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html

I just add this option and build the app again, now, I can correctly see the type info under GDB. (But the generated exe file is about two times bigger than before , also when running command "ptype wxCommandEvent", GDB takes about 30 seconds to give the response, I have already disable the pretty-printer for types, if it was enabled, it will take much longer time, see: Bug 15412 – Performance regression in "info {func,var,types} foo" (mostly info types).)

[oBFusCATed]

So, I'm not sure I've got who is to blame? GDB or GCC? Where would you report a bug?

[ollydbg]

So, I'm not sure I've got who is to blame? GDB or GCC? Where would you report a bug?

No body to blame, if you add "-femit-class-debug-always" option, you get everything expect.

About the performance issue, it is an gdb issue.

[oBFusCATed]

No body to blame, if you add "-femit-class-debug-always" option, you get everything expect.

And this is not on by default for a reason I suppose.

About the performance issue, it is an gdb issue.

Yes, but this is because there is too much data.
Can you try to contact the gdb devs to see what is their opinion?

[p2rkw]

@ollydbg: is value of 'event' correctly displayed in watches window? If not try to cast it to 'wxCommandEvent' (without reference).

[ollydbg]

@ollydbg: is value of 'event' correctly displayed in watches window?

If the app link to a wx-release-library, and you does NOT use the "-femit-class-debug-always", then nothing will shown in the watch window.
See log:

Code

[debug]> whatis event
[debug]type = wxCommandEvent &
[debug]>>>>>>cb_gdb:
[debug]> output event
[debug](wxCommandEvent &) @0x22fb34: <incomplete type>>>>>>>cb_gdb:

If not try to cast it to 'wxCommandEvent' (without reference).

It is already wxCommandEvent, right? See the log previous and also my first post.

Yes, but this is because there is too much data.
Can you try to contact the gdb devs to see what is their opinion?

The GDB devs already noticed this regression, so they have a bugzilla report: Bug 15412 – Performance regression in "info {func,var,types} foo" (mostly info types).

[oBFusCATed]

Then why -femit-class-debug-always is not on by default for C++ code?

[Wyrm]

Then why -femit-class-debug-always is not on by default for C++ code?

If I understand gcc man page correctly, the compiler does not want to include the debug info into each translation unit that included that class header. This makes sense since you don't want replicas of the debug info littered over all object files. The flag you quoted overrides this default behavior and you'll end up with debug info in each object file.

Ollydbg,
I don't know wxWidgets well enough but I observed a similar problem with a generic library when I have my code compiled against the _release_ version of that library. Is it possible that the wxWidgets library you are linking to is compiled without -g flag? Can you try linking to the debug version of that wxWidgets? Just a guess.

[ollydbg]

Then why -femit-class-debug-always is not on by default for C++ code?

If I understand gcc man page correctly, the compiler does not want to include the debug info into each translation unit that included that class header. This makes sense since you don't want replicas of the debug info littered over all object files. The flag you quoted overrides this default behavior and you'll end up with debug info in each object file.

Hi, Wyrm I think this is a reasonable answer. Thanks.

Ollydbg,
I don't know wxWidgets well enough but I observed a similar problem with a generic library when I have my code compiled against the _release_ version of that library. Is it possible that the wxWidgets library you are linking to is compiled without -g flag? Can you try linking to the debug version of that wxWidgets? Just a guess.

You are right, as you said, if I link to the debug version of wxWidgets library, then I don't have such issue. Thanks.