diff mbox

[committed] MIPS: Don't infer IRIX OS ABI from generic section names

Message ID alpine.DEB.1.10.1409092307110.27075@tp.orcam.me.uk
State Committed
Headers

Commit Message

Maciej W. Rozycki Sept. 9, 2014, 11:04 p.m. UTC 
  Hi,

 The recent addition of the `.MIPS.abiflags' section triggered a nasty 
problem early on in mips-linux-gnu regression testing:

[...]
_start () at .../gdb/testsuite/gdb.asm/asmsrc1.s:14
14              gdbasm_startup
(gdb) continue
Continuing.

Breakpoint 1, main () at .../gdb/testsuite/gdb.asm/asmsrc1.s:42
42              gdbasm_several_nops
(gdb) f
#0  main () at .../gdb/testsuite/gdb.asm/asmsrc1.s:42
42              gdbasm_several_nops
(gdb) PASS: gdb.asm/asm-source.exp: f at main
n
warning: Remote failure reply: E01
ptrace: Input/output error.
input_interrupt, count = 1 c = 36 ('$')
Ignoring packet error, continuing...
FAIL: gdb.asm/asm-source.exp: next over macro (timeout)
s
Ignoring packet error, continuing...
Ignoring packet error, continuing...
FAIL: gdb.asm/asm-source.exp: step into foo2 (timeout)
info target
Ignoring packet error, continuing...
Ignoring packet error, continuing...
FAIL: gdb.asm/asm-source.exp: info target (timeout)
info symbol 0x0
Ignoring packet error, continuing...
FAIL: gdb.asm/asm-source.exp: info symbol (timeout)
list
Ignoring packet error, continuing...
Ignoring packet error, continuing...
FAIL: gdb.asm/asm-source.exp: list (timeout)
search A routine for foo2 to call
Ignoring packet error, continuing...
Ignoring packet error, continuing...
FAIL: gdb.asm/asm-source.exp: search (timeout)
f
Ignoring packet error, continuing...
FAIL: gdb.asm/asm-source.exp: f in foo2 (timeout)
n
Ignoring packet error, continuing...
Ignoring packet error, continuing...
FAIL: gdb.asm/asm-source.exp: n in foo2 (timeout)
bt 10
Ignoring packet error, continuing...
Ignoring packet error, continuing...
FAIL: gdb.asm/asm-source.exp: bt ALL in foo2 (timeout)
bt 2
Ignoring packet error, continuing...
FAIL: gdb.asm/asm-source.exp: bt 2 in foo2 (timeout)
s
Ignoring packet error, continuing...
Ignoring packet error, continuing...
FAIL: gdb.asm/asm-source.exp: s 2 (timeout)
n
Ignoring packet error, continuing...
Ignoring packet error, continuing...
FAIL: gdb.asm/asm-source.exp: n 2 (timeout)
bt 3
Ignoring packet error, continuing...
FAIL: gdb.asm/asm-source.exp: bt 3 in foo3 (timeout)
info source
Ignoring packet error, continuing...
Ignoring packet error, continuing...
FAIL: gdb.asm/asm-source.exp: info source asmsrc1.s (timeout)
finish
Ignoring packet error, continuing...
Ignoring packet error, continuing...
FAIL: gdb.asm/asm-source.exp: finish from foo3 (timeout)
info source
Ignoring packet error, continuing...
FAIL: gdb.asm/asm-source.exp: info source asmsrc2.s (timeout)
info sources
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
[And then so on, ad infinitum.]

At this point the test suite is irrecoverable, for some reason the harness 
does not want to terminate this test case, so testing never progresses any 
further.

 I think we have 3 bugs here:

1. GDB/gdbserver fails with the `n' (`next') command.

2. GDB does not handle the `E01' error reply from a failed `vCont' packet.

3. The harness does not timeout and recover.

I'll be handling issue #1 here only, leaving the other two open.

 The problem here is we've got assembly source that does not have the 
usual ABI tag GDB normally infers the OS ABI from.  As a result it resorts 
to an old way of concluding that the OS ABI is IRIX if there are any 
sections whose names start with `.MIPS.' present in the executable.  As a 
result of setting this OS ABI, GDB concludes `ptrace(PTRACE_SINGLESTEP, 
...)' is available that I infer on IRIX is.  Consequently it does not 
internally install the software single-stepper `mips_software_single_step' 
and issues a `vCont;s...' packet instead.  In response to that `gdbserver' 
tries to issue the said `ptrace' request, that fails with EIO and the 
reply packet propagates the error.  But GDB ignores the error reply and 
insists the packet has succeeded.

 This is not a new problem, it just used not to trigger in my testing 
because gdb.asm/asm-source.exp is only run for the default multilib and I 
only ran testing with o32 being the default.  With the n64 ABI being the 
default there would already be a `.MIPS.options' section present in any 
Linux executable triggering the same problem.  A third section that is 
also present in SVR4 Linux executables these days (so again, not o32 PLT 
ones) is `.MIPS.stubs'.  This brings us with the obvious solution, that is 
excluding these generic section names from deciding on the OS ABI.

 I've checked a random IRIX executable I've had handy and it has plenty of 
other sections whose names start with `.MIPS.':

.MIPS.content.MIPS.stubs
.MIPS.content.data
.MIPS.content.fini
.MIPS.content.got
.MIPS.content.got_2
.MIPS.content.init
.MIPS.content.interp
.MIPS.content.lit4_2
.MIPS.content.lit8_1
.MIPS.content.lit8_2
.MIPS.content.rodata
.MIPS.content.sbss_1
.MIPS.content.sbss_2
.MIPS.content.sdata_1
.MIPS.content.sdata_2
.MIPS.content.srdata_1
.MIPS.content.srdata_2
.MIPS.content.text
.MIPS.content_MIPS_eh_region
.MIPS.content_MIPS_eh_region_supp
.MIPS.events.MIPS.stubs
.MIPS.events.fini
.MIPS.events.init
.MIPS.events.text
.MIPS.interfaces
.MIPS.options
.MIPS.stubs
.MIPS.symlib

so I think excluding these that are present in Linux executables won't 
hurt.

 This does not affect the case where the IRIX OS ABI is the default, e.g. 
GDB configured for the mips-sgi-irix6 target.  And if all else fails, then 
an automatically selected OS ABI can be overridden with `set osabi'.

 I have verified this change to work correctly in mips-linux-gnu 
regression testing and committed now.

2014-09-09  Maciej W. Rozycki  <macro@codesourcery.com>

	gdb/
	* mips-irix-tdep.c (mips_irix_elf_osabi_sniff_abi_tag_sections):
	Exclude `.MIPS.abiflags', `.MIPS.options' and `.MIPS.stubs' from
	the list of sections determining GDB_OSABI_IRIX.

  Maciej

gdb-mips-irix-abi-tag.diff

Comments

Matthew Fortune Sept. 10, 2014, 7:19 a.m. UTC | #1 
> The problem here is we've got assembly source that does not have the 
> usual ABI tag GDB normally infers the OS ABI from.  

Could you explain what 'usual ABI tag' refers to in this context?
I have a feeling there's another layer of ABI annotation that I
haven't seen yet.

>  I have verified this change to work correctly in mips-linux-gnu
> regression testing and committed now.

Thanks for tracking this down it must have been quite time consuming.
I'll try to sort out running some GDB tests for any further ABI
related work. I certainly wouldn't have guessed that .MIPS.abiflags
would break GDB.

Thanks,
Matthew
Maciej W. Rozycki Sept. 10, 2014, 11:50 a.m. UTC | #2 
On Wed, 10 Sep 2014, Matthew Fortune wrote:

> > The problem here is we've got assembly source that does not have the 
> > usual ABI tag GDB normally infers the OS ABI from.  
> 
> Could you explain what 'usual ABI tag' refers to in this context?
> I have a feeling there's another layer of ABI annotation that I
> haven't seen yet.

 The thing that you get from glibc's csu/abi-note.S.

> >  I have verified this change to work correctly in mips-linux-gnu
> > regression testing and committed now.
> 
> Thanks for tracking this down it must have been quite time consuming.

 Not quite so, the hard part was realising that `vCont;s...' is not 
supposed to happen for a software-stepping target, the rest was easy.

 Actually it shows a deficiency in the way GDB works, that I believe has 
already been discussed, in that the switch between software and hardware 
stepping shouldn't really be arbitrary as it is now.  Instead it should be 
the stub or the native backend that should report to the core of GDB 
whether hardware stepping is supported.

 Also right now the MIPS backend of `gdbserver' seems to know that 
hardware stepping is not supported, but it only uses that knowledge in 
some contexts and issues this `ptrace(PTRACE_SINGLESTEP, ...)' request 
anyway.

> I'll try to sort out running some GDB tests for any further ABI
> related work. I certainly wouldn't have guessed that .MIPS.abiflags
> would break GDB.

 Well, the thing is in a sense it didn't break GDB, just revealed existing 
breakage, a place to be careful about and the lack of coverage at least in 
my testing.  So I think it was good after all.

  Maciej
diff mbox

Patch

Index: gdb-fsf-trunk-quilt/gdb/mips-irix-tdep.c
===================================================================
--- gdb-fsf-trunk-quilt.orig/gdb/mips-irix-tdep.c	2014-08-23 01:11:20.000000000 +0100
+++ gdb-fsf-trunk-quilt/gdb/mips-irix-tdep.c	2014-09-09 05:24:53.037976725 +0100
@@ -38,12 +38,16 @@  mips_irix_elf_osabi_sniff_abi_tag_sectio
   name = bfd_get_section_name (abfd, sect);
   sectsize = bfd_section_size (abfd, sect);
 
-  if (strncmp (name, ".MIPS.", 6) == 0 && sectsize > 0)
-    {
-      /* The presence of a section named with a ".MIPS." prefix is
-         indicative of an IRIX binary.  */
-      *os_ident_ptr = GDB_OSABI_IRIX;
-    }
+  /* The presence of a section named with a ".MIPS." prefix is usually
+     indicative of an IRIX binary, however there are exceptions that
+     are present universally, so check for those names and avoid
+     switching away from the default OS ABI in the case of a match.  */
+  if (strncmp (name, ".MIPS.", 6) == 0
+      && strcmp (name, ".MIPS.abiflags") != 0
+      && strcmp (name, ".MIPS.options") != 0
+      && strcmp (name, ".MIPS.stubs") != 0
+      && sectsize > 0)
+    *os_ident_ptr = GDB_OSABI_IRIX;
 }
 
 static enum gdb_osabi