Message ID | alpine.DEB.1.10.1112132001040.5354@tp.orcam.me.uk |
---|---|
State | New |
Headers | show |
"Maciej W. Rozycki" <macro@codesourcery.com> writes: > 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. > 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. > 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. Anyway, whatever does end up going in to trunk really does need to be tested against trunk first. Richard
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
"Maciej W. Rozycki" <macro@codesourcery.com> writes: >> > 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? Yeah. As an example: http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg00393.html which doesn't look to bad. Clean fortran results, which I expect would test the FP interworking fairly heavily. (It's certainly been a source of bug fixes in the past, although I don't remember the results ever being terrible.) FAOD, this is with normal MIPS libraries and mips16 executables. There's still no way of building mips16 multilibs out of the box. Richard
On Tue, 8 May 2012, Richard Sandiford wrote: > > Are you using a hard-float multilib for your -mabi=32/-mips16 Linux > > testing? > > Yeah. As an example: > > http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg00393.html > > which doesn't look to bad. Clean fortran results, which I expect > would test the FP interworking fairly heavily. (It's certainly > been a source of bug fixes in the past, although I don't remember > the results ever being terrible.) Yes, these look very good indeed. Especially with QEMU that I do not feel terribly confident about as far as MIPS16 emulation is concerned (I still need to track down a single piece of real silicon supporting both MIPS64 and MIPS16 code at a time). > FAOD, this is with normal MIPS libraries and mips16 executables. > There's still no way of building mips16 multilibs out of the box. I've checked some notes and the issue was with MIPS16 FP PIC code (and therefore obviously SVR4 stubs rather than PLT) indeed. I hope these pieces will get submitted eventually. Maciej
Index: gcc-fsf-trunk-quilt/gcc/config/mips/mips.c =================================================================== --- gcc-fsf-trunk-quilt.orig/gcc/config/mips/mips.c 2011-12-13 05:02:12.605606194 +0000 +++ gcc-fsf-trunk-quilt/gcc/config/mips/mips.c 2011-12-13 05:08:42.915611245 +0000 @@ -6032,6 +6032,9 @@ mips16_build_function_stub (void) within this file. */ ASM_OUTPUT_DEF (asm_out_file, alias_name, fnname); + debug_hooks->source_line (locator_line (prologue_locator), + locator_file (prologue_locator), 0, true); + switch_to_section (function_section (current_function_decl)); }