Re: GDB and ARM Frame Pointer strangeness

[Ian Lance Taylor <ian@wasabisystems.com>]

Steven Johnson <sjohnson@neurizon.net> writes:

> 3. It is a pipe dream to say "all stubs should be immune to bad memory
> reads" its certainly an ideal goal, but unfortuantely it can not
> always be achieved.

Let's get concrete about this one.  Why can this not always be
achieved?  Every stub that I've ever worked with achieves it.

For example, let's look at gdb/i386-stub.c, which is a sample stub for
the i386.  This stub presumes the existence of an external function
exceptionHandler which causes a specified function to be a trap
handler for a specifed exception.  For, e.g., exception 13, the stub
installs a trap handler which, among other things, calls the macro
CHECK_FAULT.  That macro checks whether the global variable
_mem_fault_routine is non-zero.  If it is, the exception handler calls
it in a somewhat tricky fashion, and then returns from the exception.

When the stub is asked to read from a memory location, it sets
_mem_fault_routine to set_mem_err.  The set_mem_err function just sets
the global variable mem_err to 1.

The effect is that if the read from memory is from an invalid address,
the function set_mem_err is called, and the program continue running.
After the memory is fetched, the code checks mem_err.  If mem_err is
set, the memory address was invalid, and the stub indicates that to
the caller.

That is a concrete example of how a common stub handles this issue.
That general approach is used by every stub I've worked with.  Every
processor must give you some mechanism to trap invalid memory
addresses.  If it doesn't, many things become impossible.

If we want to continue this discussion, please explain why your stub
can not do something similar.

Ian