Opened 3 years ago

Closed 3 years ago

#13799 closed bug (fixed)

Debugger doesn't display variables and registers in runtime_loader

Reported by: KapiX Owned by: bonefish
Priority: normal Milestone: Unscheduled
Component: Build System Version: R1/Development
Keywords: runtime loader Cc: bonefish, korli
Blocked By: Blocking:
Platform: All


I have built runtime_loader and libroot with DEBUG enabled and booted the resulting system, and the Debugger loads the source files for runtime_loader, but I don't see variables and registers.

gcc2h hrev51597

Files to reproduce here:

Change History (5)

comment:1 by anevilyak, 3 years ago

I've grabbed the files in question if you want to remove them from your host again. I'll try to look into this in the next few days as time permits.

comment:2 by anevilyak, 3 years ago

Cc: bonefish korli added
Component: Applications/DebuggerBuild System
Keywords: runtime loader added
Owner: changed from anevilyak to bonefish

After reproducing this and looking at a dump of the runtime loader's ELF sections, the issue here is actually relatively "straightforward". The final binary for the loader is winding up with every .debug information section *except* one of .{debug,eh}_frame. As a result, the actual instructions needed to unwind the stack frames are not available, and consequently also the necessary data to resolve variables/full registers. However, I'm uncertain as to why this is occurring. It may have to do with the custom ldscripts used to link the loader. CCing a few people who might be able to shed some light.

comment:3 by pulkomandy, 3 years ago

The eh_frame is in the DISCARD section here, which would explain it being removed?

in reply to:  3 comment:4 by anevilyak, 3 years ago

Replying to PulkoMandy:

The eh_frame is in the DISCARD section here, which would explain it being removed?

Would there be any potential problem with adding it back? Alternatively, is it possible for the linker script to distinguish between a build with debugging information vs one without when deciding whether or not to discard? I assume that was simply done initially as an optimization, since the loader is compiled with -fno-exceptions, which would theoretically make that section unnecessary under normal circumstances.

comment:5 by anevilyak, 3 years ago

Resolution: fixed
Status: newclosed

Fixed in hrev51647.

Note: See TracTickets for help on using tickets.