A couple of thoughts/queries.

John Reimer terminal.node at gmail.com
Wed Dec 26 23:30:22 PST 2007


Cristian Vlasceanu wrote:
> John Reimer wrote:
>> On Wed, 26 Dec 2007 10:33:40 +0100, Lars Ivar Igesund wrote:
>>
>>> Bill Baxter wrote:
>>>> If you're not on Windows then I presume gdb works?  I guess that
>>>> doesn't have any D-specific knowledge.  Support for D in zerobugs is
>>>> still vaporware?
> The debugger cannot help much when the debug information produced by the 
> compiler is not 100% accurate.
> 
>>> I did a quick test, and zerobugs has at least some D support. Types
>>> seems to be correctly demangled in the variables view, whereas functions
>>> and method names in the stack trace are not. I wasn't immediately able
>>> to pinpoint the location of my segfault though (a real one that I knew
>>> of), although the stacktrace showed up. Definately better looking than
>>> gdb, all in all :)
>>  
> 
> An outline of how ZeroBUGS handles stack unwinding: if there is DWARF 
> information present, then look for frame-unwinding information. 
> Otherwise, assume the System V ABI for the i386 and PowerPC and Itanium 
> ABI for X86_64.
> 
> Again, do not blame the debugger for what the compiler does not produce.
> 
> Unless you have a 100% accurate stack trace from another debugger for 
> the same executable and platform, in which case I do beg you to send me 
> a bug report.
> 
> 
>> Yes, just recently I've been experimenting with zerobugs.  It was much 
>> easier to use with D than the other linux debuggers since D symbols 
>> are demangled. 
> 
> I use a very slightly modified version of Thomas Kuehne's demangler 
> (basically I added a function to show his copyright when I display the 
> About window, and tweaked the config.h). It is built as a shared object 
> so  you are free to tinker with it, the code is here: 
> http://www.zerobugs.org/demangle_d.tgz
> 
> 
> 
>> The stacktrace does kind of show the general position of the segfault 
>> also.  I like the way it opens any associated shared libraries and 
>> shows the disassembly in a new tab as you step into the function calls.
>>
>> One frustration is that char[] still are represented as a length and 
>> pointer, thus you don't get to see the text object associated with it. 
>> But even then, sometimes you can see it by expanding the related tree 
>> for the ptr object.
>>
> Do you have an associative array of chars, or just char[]? Associative 
> arrays do not work yet (it is coming though, I promise), but char[] 
> should work I just tried it today with dmd 2.0, see snapshot here: 
> http://zero-bugs.com/zero-char.png
> 
> Best Regards and a Happy new Year();
>  Cristian

The arrays are not associative.  They are char[][] from the main 
argument list.  I'm not sure why they weren't working.  Maybe I have an 
older version?  I'll have a look.

You've done great work with zerobugs, Christian.  Thanks for the 
contribution, despite the odds. :o)

-JJR



More information about the Digitalmars-d mailing list