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 testing? > 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. Maciej
