This is the mail archive of the
mailing list for the GDB project.
RE: [committed] MIPS: Don't infer IRIX OS ABI from generic section names
- From: "Maciej W. Rozycki" <macro at codesourcery dot com>
- To: Matthew Fortune <Matthew dot Fortune at imgtec dot com>
- Cc: "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>, Joel Brobecker <brobecker at adacore dot com>, Richard Sandiford <rdsandiford at googlemail dot com>
- Date: Wed, 10 Sep 2014 12:50:56 +0100
- Subject: RE: [committed] MIPS: Don't infer IRIX OS ABI from generic section names
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot DEB dot 1 dot 10 dot 1409092307110 dot 27075 at tp dot orcam dot me dot uk> <6D39441BF12EF246A7ABCE6654B0235320F07EC6 at LEMAIL01 dot le dot imgtec dot org>
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
> 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.