[Simh] trouble selecting VAX ethernet on CentOS

[Michael Bloom]

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.