On Monday 01 November 2010 07:53, Timo Teräs wrote: > >>> It needs to be saved/restored *if ebx is used*. In these stubs it is > >>> not used, thus it is not saved by gcc, and therefore tail jump is ok > >>> even with __PIC__. > >>> > >>> I do not merely think so. I tested it. Try in the directory > >>> where you successfully built shared uclibc using PIC: > >> > >> I remember that the original crash I fixed was caused by PIC and not > >> SSP. The issue is that the jmp target name is outside __asm__ "" and > >> translated by gcc to ebx+xxx. So you use implicitly ebx in your __asm__ > >> block. And thus gcc will save/restore and calculate the local ebx for > >> you automatically. > > > > Uhhuh... so it will happen only if function gets called through > > inter-library stub. This should not happen with __GI_foo symbols, though - > > those are hidden and should be linked directly intra-library. > > > > BTW, there were no __GI_foo calls originally, I just called foo directly > > at first. Then affed __GI_ prefix. Maybe *that* fixed the problem. > > I think you had __GI_ prefix all the time. I rebuilt again with the > original buggy config. It had both PIC and SSP enabled. The SSP abort > __stack_chk_fail is called via plt and causes the ebx load. So using > __SSP_ALL__ fixed this specific build.
... > Yes, regular PIC and PIC+SSP now works. BUT, several other features do not. > > If I'm building with "-fPIC -pg" it instruments all C functions with > profiler stuff which is called via PLT and causes EBX reloads > --> crash > > -fno-omit-frame-pointer is sometimes useful for profiling too > --> crash > > Also the upcoming -fsplit-stack will be broken by this too (that might > need additional uclibc support though). > > And I'm pretty sure there's also other similar compiler features. > There's no predefined #defines in gcc for any of these. > > What I'm trying to say that there are *numerous* situations when the > compiler can create stack frame for you without you ever knowing it. And > if you want to do a tail jump, you really should be doing it from .S > file where you control fully the prologue/epilogue code. (GCC naked > attribute does not seem to work on x86.) You convinced me. I deleted the optimization altogether and pushed the change to git. Sooner or later, we will need proper long double functions anyway, thus why optimize something we are going to replace? -- vda _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
