[M3commit] CVS Update: cm3

[Tony Hosking]

Is this only a WIN32 problem?  Why has this not showed up on other  
platforms?

On Apr 29, 2008, at 12:32 PM, Jay Krell wrote:

> 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.