[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