On 02/29/2012 15:38 PM, Michael L. Umbricht wrote:
With no special options to "make vax" I do get "push %rbp" from "disas eth_open"
Thanks, Michael. That is good to know.
Thanks also to Mark, for the explanation about the stack trashing. (Perhaps pthread_attr_setguardsize() or the equivalent where available, might help to help prevent such a bug from affecting it's debuggability?)
The source of my worry had been this: I've seen several systems (they were not not linux, though) in which insufficient thought had been given to the needs of debugging when setting up the stack after the occurrence of a trap.
On one such (SystemV R3) system, I ended up rewriting part of the trap handling code so that an expanded signal info frame, that was placed on the stack, placed a copy of the frame pointer in the same relative position that it would have been in had the handler been invoked by a subroutine call so that the debugger could easily trace (from the signal handler, if the signal was caught) back to the routine where the trap had been generated, with no gaps resulting from insufficient thought in design.
The only tricky part was making it backward compatible so that old binaries would still run correctly. To do this, my new signal trampoline took advantage of the fact that the old binaries were looking for a flag placed on the stack in the event of traps like SEGV's having happened at user level to tell them to issue a specific return-from-signal sys3b() call (despite it being a 68020 machine not a 3b2). If it was an old binary, it would look for the flag and use the old mechanism, but a new binary would be aware it was in a BSD style signal trampoline and use a BSD style sigreturn() that had been added in support of the new mechanism. It's so long ago, I no longer remember the details clearly, but the improvement in debuggability was so dramatic that I subsequently modified the kernel to save the frame pointer on all traps so that panic dumps could be debugged just as easily, at only a very slight cost in kernel time.
When I saw that stack, and read in the gcc manual page that the default for frame pointer generation on intel machines had been reversed, I guess I panic'ed a bit myself. But, empirical evidence seems to show the manual page to be wrong in that regard.
_______________________________________________ Simh mailing list [email protected] http://mailman.trailing-edge.com/mailman/listinfo/simh
