[haiku-development] Re: Jamming in debugging info?
- From: pete.goodeve@xxxxxxxxxxxx
- To: haiku-development@xxxxxxxxxxxxx
- Date: Tue, 14 Jul 2009 00:37:11 -0700
On Mon, Jul 13, 2009 at 08:54:59PM -0500, Rene Gollent wrote:
>
> No. What he meant is this, from UserBuildConfig.ReadMe line 37 :
>
> SetConfigVar DEBUG : HAIKU_TOP src system boot loader : 1 : global ;
>
> In your particular case, this would be HAIKU_TOP src add-ons kernel
> drivers midi usb_midi : 1 : global ;
Heh -- I'd tried exactly that line before I read your response...
*However*, what had slipped past me entirely, with my unfamiliarity
with jam [and probably reading too fast as usual...] is that UserBuildConfig
should be in that build/jam directory! I'd sort of just assumed it should
be in the working directory [though I do now see it says "rename" rather
than "copy"!]
Unfortunately though, Ingo's suggestion of
> readelf --debug-dump=decodedline <file>
doesn't do anything at all, except tell me that "decodedline" is an
unrecognized option. (Not in the man page, either.) objdump gave me
what I needed though, once I had the debug binary.
>
>
> > (It's a vm_page_fault, incidentally, which seems a
> > bit odd in code that should be entirely kernel space.)
>
> Not unusual at all, kernel space is the only place that particular
> panic can happen, since if a userland app accesses an invalid address
> like this, it will just trigger a SIGSEGV and be terminated. Bear in
> mind once the MMU is enabled during boot, it stays on, regardless of
> whether you're in userspace or the kernel, which is also important
> since at least parts of the kernel are also pageable. The kernel
> simply has a different set of page mappings.
>
Ah, I see. Very fuzzy on this sort of thing, I'm afraid.
With the new information, I've been able to establish exactly
where the fault is hit, but it hasn't helped much! It seems to be
cleanup code after the closing brace of an if-then-else block, but
I've no idea what gets done for that. The instruction that triggers
it is "mov 0x4(%ecx, %edx"), with ecx containing 0xccccccc, so it
bombs on an access of 0xccccccd0, but I can't really follow the
route it takes to get there.
Is this something that should get a specific ticket? I could paste
the code involved, or relevant parts, there.
Thanks,
-- Pete --
Other related posts:
