Re: MIPS Linux signals

Maciej W. Rozycki
2012-05-21T22:34:01Z

On Mon, 21 May 2012, Michael Eager wrote:

> > What target are you specifically referring to? Can you describe a
> > scenario where it happens?
>
> Debugging a MIPS core file. Pedro suggested that no one
> would ever see this running gdbserver.

Well, these are mutually exclusive -- you can't open a remote target and
a core file both at a time, and it's only the signal number that's
recorded in the core image as the cause of termination that's causing
trouble. I wonder if there's more stuff there actually that needs
mapping.

> > Ah, so that is with the core file target used in a cross-debugger, right?
> > Well, no wonder nobody has noticed, this is a very unusual scenario -- I
> > have used GDB for at least 15 years now and may have had a need to examine
> > a core file with a cross-debugger perhaps once or twice -- and then some
> > common signals looked for like SIGSEGV or SIGILL are identity mapped (and
> > I knew the signal that caused the core file dumped beforehand anyway as
> > it's printed as the program is being killed anyway).
>
> Yes, this may be less common than I first thought. SEGVs are much
> more common than SIGBUS.

Actually you'll only see SIGBUS in two cases under MIPS/Linux:

1. An unaligned memory access -- these trap into the kernel if not made
correctly (with the special unaligned access instructions) and are
normally emulated by the kernel at a large performance expense for data
accesses. You can still get one if you try to execute unaligned
instructions (e.g. MIPS16 code on a processor that does not support
that mode of execution; MIPS16 code addresses have the lowest bit set),
try to access unaligned data outside the user address space (USEG or
XUSEG as applicable; the lack of alignment takes precedence over MMU
protection) or if you disable the kernel emulation with the obscure
syscall that's there for special cases.

2. You actually get a true bus error signalled by system logic in an
external bus transaction, e.g. an uncorrected memory ECC error or
suchlike.

As you can see it's all pretty obscure and uncommon stuff.

> > Also by the look of it, such changes will actually be required for all
> > processor/OS targets as obviously when you have e.g. a MIPS/IRIX-host
> > cross-debugger targetting i386/Linux then the signal numbers won't match
> > again, except that in the other direction. That certainly begs for a
> > general solution, perhaps like one used by the RSP where the GDB core uses
> > generic signal numbers the target side translate to/from them as
> > appropriate (obviously the host OS may have no notion of signals at all).
>
> Yes.
>
> I'm not sure about creating a generic solution. The same solution can
> be adapted to Solaris or other OS's which have different signal value
> assignments, but a solution for a target which doesn't have signals,
> that would call for a target-based (i.e., gdbserver or core generation)
> solution.

Targets with no signals are not a problem, they simply won't produce or
accept any. It's the hosts that are a problem -- generic code in
common/signals.c has stuff like this:

#if defined (SIGHUP)
case TARGET_SIGNAL_HUP:
return SIGHUP;
#endif

that obviosuly won't work on on a host that doesn't have such a signal
defined (I'm not sure if hosts like MinGW or DJGPP pretend that these
signals exist there, that would make little sense; there may be others as
well). As long as every target that supports signals provides its mapping
similar to one you did, then I think we should be fine.

And actually, as far as Linux is concerned, I suppose we can actually
have a common mapping that will cover most of the processor architectures
Linux supports as most if not all of the modern ports have standardised on
a common set of magic numbers, as far as I know. So linux-tdep.c would
default to that standard mapping and then any oddball port would override
that choice with their own.

It's only the few older ports that had their reasons, legitimate or not,
to stick to other definitions that are different -- for the MIPS port for
example there used to be an idea once to run IRIX binaries using a foreign
kernel personality and an ABI compatibility layer (similar to iBCS the
i386/Linux port used to support) -- reusing the same magic numbers would
certainly make the effort easier (many kernel structures exposed via
syscalls are like those from IRIX rather than other Linux ports for the
very same reason). To the best of my knowledge this idea never fully
materialised, but these provisions have stayed for backwards compatibility
with the early decisions.

Another example is the Alpha/Linux port and its actual possibility to run
DEC OSF/1 (or Digital Unix or Tru64 Unix or whatever, hmm, lost track...)
binaries; these are not ELF even, but ECOFF. There are probably a few
more (<linux/personality.h> suggests SunOS and Solaris, presumably on
SPARC and HP-UX presumably on HP-PA), but the rest should be pretty
uniform.

Maciej