Re: MIPS Linux signals

["Maciej W. Rozycki" <macro at codesourcery dot com>]

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