Executable file loading from weaver.elf

[Sven Fülster]

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