Hi Norman,
we use only one PD declaration (in our example, it is named "modules") that serves as a container for all boot modules provided by core's ROM service. Elfweaver regards the specified files as plain binary data and just concatenates them in the resulting single-image.
Ok, I've wondered how the original linkaddress would be preserved.
Instead you will need to set the breakpoint to the virtual address of your program starting at the virtual address 0x2000000. However, each program is linked to the same virtual address (defined in base-okl4/mk/spec-okl4_x86.mk). So the use of breakpoints when executing multiple processes may still be cumbersome because of the aliasing of the processes' virtual address spaces.
That was a nasty experience when I worked in the l4ka-pistachio case without elfweaver. The gdbserver just sends virtual addresses to the host, where gdb maps them to the currently loaded binary - regardless of the actual running process, indeed.
Init chooses the base address as found in the ELF header of your program. Have you already tried using the original link address?
I've just tried loading the symbol file into gdb without providing an extra address and now the behaviour in the elfweaver case is the same as in the l4ka case.
BTW, if you succeed in using qemu for debugging, would you like to write up your experience as a Wiki page at genode.org? I think that your experience could be very valuable for other developers as well.
,-)
Don't consider me so smart that this could be really helpful :)
There are a few ideas so far:
1. Assume the case you have a breakpoint in main. When booting the system, this breakpoint will be triggered several times, and you will have to check each time if you're in the right process (have you seen a printf telling you that your binary is started right now? Does the stack trace make sense? When you see that printf calls dde_thread_main, that could be suspicious. Do your local variables contain sensible data?
This is not really annoying. Things become nasty as soon you start to step through your code and suddenly another thread is scheduled.
If you step by machine instructions rather than by source line, the former won't happen because in this mode, interrupts are disabled (stepping by source line corresponds to a continuation to a next breakpoint). But this is boring when you want to step over more than a few instructions.
2. Enhance the gdbserver
3. Provide a special linkaddress for that program you want to debug just at build time. I think this is the way I'll try out for a start.
And yes, I don't think we'd keep our 'best practices' a secret as soon as we've learned them :)
Thank you for the expeditious explanation.
Sven -- Sven Fülster