RE: RFC GDB Linux Awareness analysis

duane> 7) A good example of scripting is during postmortem debug
duane> GDB cannot call (execute) a helper function within the 
duane> target because the target is not “live”

doug> Depends on what the helper function does of course.
doug> E.g., it's possible to resurrect a corefile (assuming it hasn't
been
doug> truncated, etc.) enough to run a pretty-printer contained in the 
doug> app (as opposed to in python).

Yes, as you said "it depends on what it does"

I would say almost categorically you *cannot* use the target pretty
printer.

Bare metal is often a synonym for "cross compiling". That means
host != target, and loading a complete image into a real target is 
not always viable, or possible. (ie: You may need to construct
MMU page tables, or initialize memory decoders, or DDR to make memory
work.

The advantage is: The Target CPU might be able to execute opcodes :-)

The easier method is loading into a 'memory only' emulation, and do not 
support execution. Yes, you could use an opcode simulator... (ie: the 
armulator) but that is not viable for all CPU types.

Using your "pretty print" solution as the example - another problem is
the run time library support. I'll bet it would be very helpful to use
the targets version of "printf()" in some way (maybe sprintf())

The problem is often the underlying printf() routines in the target 
C library in some cases [often!] use malloc/free to manage buffers

And thus, often make use of some OS feature like a semaphore or mutex.
Thus, while calling this special function interrupts get turned back on
and who knows what else get changed.

Every target is different, every embedded system is different.

Some of these pretty print problems also occur when live debugging.

This whole area is one giant rat hole of problems to make work
universally.

-Duane.