On 11/01/2010 03:16 AM, Denys Vlasenko wrote: > On Sunday 31 October 2010 23:07, Timo Teräs wrote: >> On 10/31/2010 05:10 PM, Denys Vlasenko wrote: >>> Since by breaking long double wrappers I proved that no one actually >>> runs math testsuite (does anyone runs ANY part of testsuite?), >>> I decided that now it is my obligation to fix math testsuite first, >>> so that in the future it will be easier to catch breakatge. >>> >>> I fixed it to a certain degree already. >>> >>> Then I reverted your fix, and _verified_ that it works with both >>> static and shared build. >> >> Your code crashed. Mine version did not. I did not run the test suite > > I think we all neglected testsuite for too long. It has bit rotted. > Needs work to restore to runnable state... > >> nor test the call thingy. Sorry about that. Just build failed by >> segfault vs. succeed was enough for me. > > Yes, I know how the failure must have looked on your side. > What is unclear is what caused gcc to emit a prologue > with some stack pushes... > > >>> 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. >>> Thanks, replaced: >>> >>> -#if defined __i386__ && defined __OPTIMIZE__ && !defined __UCLIBC_HAS_SSP__ >>> +#if defined __i386__ && defined __OPTIMIZE__ && !defined __SSP_ALL__ >>> >>> and pushed to git. >> >> Please add __PIC__ test. > > Do you see the failure with current git? I did __PIC__ test, it wroks for > me... 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.) _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
