Message ID | alpine.DEB.1.10.1409092307110.27075@tp.orcam.me.uk |
---|---|
State | Committed |
Headers |
Received: (qmail 26613 invoked by alias); 9 Sep 2014 23:04:24 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <gdb-patches.sourceware.org> List-Unsubscribe: <mailto:gdb-patches-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/gdb-patches/> List-Post: <mailto:gdb-patches@sourceware.org> List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 26600 invoked by uid 89); 9 Sep 2014 23:04:22 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.0 required=5.0 tests=AWL, BAYES_00 autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 09 Sep 2014 23:04:20 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=SVR-IES-FEM-02.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1XRUSO-0003Fp-NN from Maciej_Rozycki@mentor.com ; Tue, 09 Sep 2014 16:04:17 -0700 Received: from localhost (137.202.0.76) by SVR-IES-FEM-02.mgc.mentorg.com (137.202.0.106) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 10 Sep 2014 00:04:14 +0100 Date: Wed, 10 Sep 2014 00:04:09 +0100 From: "Maciej W. Rozycki" <macro@codesourcery.com> To: <gdb-patches@sourceware.org> CC: Joel Brobecker <brobecker@adacore.com>, Richard Sandiford <rdsandiford@googlemail.com>, Matthew Fortune <Matthew.Fortune@imgtec.com> Subject: [committed] MIPS: Don't infer IRIX OS ABI from generic section names Message-ID: <alpine.DEB.1.10.1409092307110.27075@tp.orcam.me.uk> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" |
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
> 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
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
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