[M3commit] CVS Update: cm3
Jay Krell
jkrell at elego.de
Tue Apr 29 12:32:10 CEST 2008
CVSROOT: /usr/cvs
Changes by: jkrell at birch. 08/04/29 12:32:10
Modified files:
cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c
Log message:
It is important to not mark internal functions such as finally blocks as public.
Otherwise what happens on AMD64_LINUX is that, for example, ThreadPThread__InitMutex's call to
its own finally block goes through the PLT, trashing the static link in r10 and
the finally block crashes.
The fix should actually be broader.
Call to any function implemented in the same "library" should not go through PLT.
I think this requires a front end change and maybe M3CGOps, in order to
communicate down just what is in the same "library".
"Interposition" and supporting ANSI C function pointer equality semantics are not interesting,
and very costly.
See
http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c.diff?r1=1.17;r2=1.18
As to if inlines that aren't exported really need to be kept, I don't know.
The fiddling with fputs vs. printf here is to workaround a strange compilation problem
on my machine -- fputs_unlocked not declared, some disconnect between configure and compile
perhaps.
As well, one call to printf vs. three to fputs achieves a similar affect as unlocked, as only
one lock is needed, albeit the format parsing is overly general, and the overall operation is
still locked.
And remove nearby tabs.
More information about the M3commit
mailing list