• Trass3r (10/10) Jun 28 2011 Starting my cl4d executable with 'gdb main -readnow' results in
• Robert Clipsham (19/29) Jun 28 2011 First: are you compiling *all* modules with -gc rather than -g?
• Trass3r (7/13) Jun 28 2011 Ah ok, somehow I was mislead into thinking that the gdb patches allow yo...

Trass3r <un known.com> writes:

Starting my cl4d executable with 'gdb main -readnow' results in

Reading symbols from main...expanding to full symbols...Die:  
DW_TAG_type_unit (abbrev 4, offset 0x6a)
   parent at offset: 0xb
   has children: FALSE
   attributes:
     DW_AT_byte_size (DW_FORM_data1) constant: 16
     DW_AT_type (DW_FORM_ref4) constant ref: 0x62 (adjusted)
Dwarf Error: Missing children for type unit [in module main]

How do you reduce/report such a bug?

Robert Clipsham <robert octarineparrot.com> writes:

On 28/06/2011 22:47, Trass3r wrote:
 Starting my cl4d executable with 'gdb main -readnow' results in

 Reading symbols from main...expanding to full symbols...Die:
 DW_TAG_type_unit (abbrev 4, offset 0x6a)
 parent at offset: 0xb
 has children: FALSE
 attributes:
 DW_AT_byte_size (DW_FORM_data1) constant: 16
 DW_AT_type (DW_FORM_ref4) constant ref: 0x62 (adjusted)
 Dwarf Error: Missing children for type unit [in module main]

 How do you reduce/report such a bug?

First: are you compiling *all* modules with -gc rather than -g?

Once you've checked that, what OS/platform are you on? Posting a binary 
will most likely be enough to fix it, but given that there's no way to 
check it's fixed without some source to work with it may be best to 
narrow down a test case.

To do that, I recommend you unleash DustMite on your source: 
https://github.com/CyberShadow/DustMite. You'll need a script that can 
test for the bug too, you can pass a command file to gdb and grep for 
the relevant failure, alternatively if you can get the failure when 
using dwarfdump/objdump that may be easier.

If your code's open source you could always just put a link to your 
source code on there, it won't take long for someone else to narrow down 
a test case if they know what they're doing (it wouldn't be the first 
time I've narrowed down several thousand lines of code to fix dmd's 
debug info :>).

-- 
Robert
http://octarineparrot.com/

Trass3r <un known.com> writes:

 First: are you compiling *all* modules with -gc rather than -g?

Ah ok, somehow I was mislead into thinking that the gdb patches allow you  
to use -g.

It works now though line numbers are more messed up than I'm used to from  
cv2pdb + VS. There I only have the usual problems with mixins but here it  
even jumps around senselessly if I just do a step over.
Don't know if this has to do with -gc or Descent.


 To do that, I recommend you unleash DustMite on your source:  
 https://github.com/CyberShadow/DustMite. You'll need a script that can  
 test for the bug too, you can pass a command file to gdb and grep for  
 the relevant failure, alternatively if you can get the failure when  
 using dwarfdump/objdump that may be easier.

Yeah need to test that tool soon.