Re: Another illegal instruction awk problem

[der Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>>> I'm not quite sure how to get gdb to disassemble the faulting
>>> instruction
>> (gdb) x/i $pc
> Thank you... I thought that was the syntax, too, but this is what I
> get:

> Core was generated by `awk'.
> Program terminated with signal 4, Illegal instruction.
> #0  0x80196183 in ?? ()
> (gdb) x/i $pc
> 0x80196183:     Cannot access memory at address 0x80196183

> Not sure what to do from here...

That's...very interesting.

Normally, when gdb "Cannot access memory at" $pc, it indicates one of
two things: (1) the code took a wild jump and crsahed because it was
trying to execute out of nonexistent (virtual) memory, or (2) it was
executing in a mapped memory segment which was not saved in the core.
For a SIGILL, I'd expect (2) to be more likely, because I'd expect (1)
to produce a memory fault signal - SIGBUS or SIGSEGV.

In this case, because we're on a VAX, I can identify 0x80196183 as
being in system space (the high two bits are 10).  Thus, either this is
a case of (1) that landed in system space by chance and generated
SIGILL rather than SIGBUS or SIGSEGV for reasons I'd have to dig around
in the VAX code to undrestand, or the NetBSD version you're using has a
user page in system space and the process was executing out of it (or
trying to - if it has a user page but it doesn't contain code, at least
not at that address, and the process jumped to it incorrectly, that
would explain everything, even the SIGILL), and either it isn't there
(at another address?) when you ran gdb or the way gdb's support
facility accesses memory can't see it.

You said this was on a 4k/60.  I don't recall whether that has any
macrocoded instructions the way the uV2 does; if so, I think they
usually end up executing emulation code inside system space in user
mode, and if that's what's happening here then this could incidate a
bug in the macrocode or it could indicate that the macrocode emulation
detected a problem and faulted deliberately.

It might be worth checking your kernel's symbol table to see if that
address is within anything known to the kernel.  It looks a bit high
for that to be very plausible to me, but I've been surprised before.

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B