User forums > General (but related to Code::Blocks)

GDB can not show the type info of wxCommandEvent

(1/3) > >>

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..."));
}

--- End code ---
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>


--- End code ---
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>

--- End code ---
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:

--- Quote from: ollydbg on May 28, 2013, 03:31:54 am ---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.

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

--- Quote ----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.

--- End quote ---

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 :D, 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?

Navigation

[0] Message Index

[#] Next page