[Haiku-commits] r31285 - haiku/trunk/src/apps/debugger/debug_info

[Ingo Weinhold]

-------- Original-Nachricht --------
> Datum: Sun, 28 Jun 2009 16:33:27 -0500
> Von: Rene Gollent <anevilyak at gmail.com>

> On Sun, Jun 28, 2009 at 12:38 PM, Ingo Weinhold<ingo_weinhold at gmx.de>
> wrote:
> > Nice. I hope we don't run into those problems as well. I wouldn't be
> > surprised, if that's just a gcc 2 problem, producing invalid debug info
> > entries. That's one of the reasons I prefer gcc 4.
> 
> I wondered if it had to with running a binary where the libs were a
> mix of debug and non-debug builds. The message specifically had to do
> with being unable to find the DIE in its internal cache, so I just
> assumed it was some issue related to that.

I don't know. Maybe that's really just a gdb bug. What made me wonder is that when I recently tried to load a gcc 2 built Haiku kernel with debug info in a current gdb, it choked (in a different way though than Haiku's gdb). One would think that a functionality as basic as reading debug info is not fundamentally broken in the most popular (or just virtually only) open source debugger that has been around for ages. At least not valid debug info. So I'm wildly guessing that maybe the debug info gcc 2 produces is not (always completely) valid.

> In any case, if it were
> invalid data structures in the DWARF info, wouldn't that have tripped
> up your debugger as well?

The DWARF debug info isn't used yet. It's loaded (partially) since yesterday, but I'm still working on actually making use of it. The method to get a stack trace is currently pretty much the same as used in the kernel debugger or the debug server, just with a bit of extra intelligence to recognize function prologues/epilogues and syscalls.

> The backtrace gdb gave me was quite
> literally unusable, ~30-40 entries most of which were ?? and those
> that weren't were in completely random places in libbe.

Yeah, gdb is a bit too easy to confuse. Not sure why.

CU, Ingo