* [committed] MIPS: Don't infer IRIX OS ABI from generic section names
@ 2014-09-09 23:04 Maciej W. Rozycki
2014-09-10 7:19 ` Matthew Fortune
0 siblings, 1 reply; 3+ messages in thread
From: Maciej W. Rozycki @ 2014-09-09 23:04 UTC (permalink / raw)
To: gdb-patches; +Cc: Joel Brobecker, Richard Sandiford, Matthew Fortune
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
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* RE: [committed] MIPS: Don't infer IRIX OS ABI from generic section names
2014-09-09 23:04 [committed] MIPS: Don't infer IRIX OS ABI from generic section names Maciej W. Rozycki
@ 2014-09-10 7:19 ` Matthew Fortune
2014-09-10 11:51 ` Maciej W. Rozycki
0 siblings, 1 reply; 3+ messages in thread
From: Matthew Fortune @ 2014-09-10 7:19 UTC (permalink / raw)
To: Maciej W. Rozycki, gdb-patches; +Cc: Joel Brobecker, Richard Sandiford
> 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
^ permalink raw reply [flat|nested] 3+ messages in thread
* RE: [committed] MIPS: Don't infer IRIX OS ABI from generic section names
2014-09-10 7:19 ` Matthew Fortune
@ 2014-09-10 11:51 ` Maciej W. Rozycki
0 siblings, 0 replies; 3+ messages in thread
From: Maciej W. Rozycki @ 2014-09-10 11:51 UTC (permalink / raw)
To: Matthew Fortune; +Cc: gdb-patches, Joel Brobecker, Richard Sandiford
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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2014-09-10 11:51 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-09-09 23:04 [committed] MIPS: Don't infer IRIX OS ABI from generic section names Maciej W. Rozycki
2014-09-10 7:19 ` Matthew Fortune
2014-09-10 11:51 ` Maciej W. Rozycki
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).