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

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

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