This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] MIPS16: Fix truncated DWARF-2 line information

Hi Richard,

 Resurrecting the issue now that I have new data.

On Wed, 14 Dec 2011, Richard Sandiford wrote:

> >  After some thinking I decided the simplest approach will be just emitting 
> > the missing location directive in the context of the MIPS16 thunk being 
> > built that will apply to the actual function prologue.  The resulting 
> > change is included below -- this just repeats the record originally output 
> > before the thunk (and which applies to .mips16.fn.sinfrob16 section).
> I think I'd prefer to change where the thunc is emitted.  We shouldn't
> really have the thunk coming between the MIPS16 code and its .cfi_startproc
> either.  And the thunk should probably have CFI info itself.
> I'll try to look at it sometime if you don't beat me to it.

 OK, whatever you prefer.  I hope that CFI data won't confuse GDB, any 
thunks should really be skipped over in regular debugging (i.e. unless you 
single-step by the machine instruction).

> >  Regression-testing this change turned out to be quite tricky as current 
> > trunk does not appear to build for the mips-sde-elf target:
> Gah.  mipsisa64-elfoabi is another option FWIW.

 I'm not sure if that's a configuration I could test without tremendous 
effort.  Thanks for fixing mips-sde-elf support though.

> > and the mips-linux-gnu configuration is not ready yet for MIPS16 testing.
> Out of interest, what goes wrong?  I've been testing -mabi=32/-mips16 on
> mips64-linux-gnu for some time without difficulty.

 I've thought some pieces are missing upstream, but perhaps I've been 
confused.  I reckon there was a nasty issue with GCC confusing the symbols 
used (using the wrong symbol alias or failing to use one) in the context 
of using MIPS16 thunks and PLT (that we discovered as soon as or shortly 
after we started using such a setup, so that wasn't anything particularly 
obscure), but perhaps the fix for that issue has been actually submitted 
and included upstream already.

 Are you using a hard-float multilib for your -mabi=32/-mips16 Linux 

> Anyway, whatever does end up going in to trunk really does need to be
> tested against trunk first.

 I did that testing now, and filed PR target/53276 so that this issue 
isn't lost.  I'll continue using the fix I proposed until you have 
implemented your suggestions; it's unlikely I'll be able to find an extra 
time slot to look into it any further given that I have a working solution 
and lots of other issues to deal with.  I can't guarantee I'll keep that 
promise though. ;)

 I have some small improvements to how some of these thunks are generated 
outstanding; I'll try to push them through testing and offer them to you 
as time permits now that I've got a reliable configuration for upstream 
GCC testing.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]