[M3devel] function pointers and comparison to nil? mis-typed function pointers?

[Tony Hosking]

On May 27, 2008, at 12:34 PM, Jay wrote:

> gcc via the C front end does more -- it allows taking the address of  
> a nested function, which generates code on the stack.
> I have NOT looked at where the line is here between the C front end  
> and the back end.
> ..but Ada and Pascal reportedly need this, and it is quite target- 
> dependent, so presumably this is a back end feature.
> Still, gcc's vaunted portability here is not clearly adequate  
> consolation and merely shifting the work to it is not clearly a good  
> move.
> (besides the integrated backend and any hypothetical LLVM backend or  
> C backend)

True, but it is deprecated and doesn't work on all platforms because  
of stack non-executability.  We compute the static chain using gcc's  
support as it is (with hacks to avoid computation of a function  
pointer via trampoline).

> I was looking into this stuff because calling the module binders in  
> RTLinker.m3 on SPARC64_OPENBSD hit an alignment fault, because  
> SPARC64 instructions are 32bits and 32bit aligned (I guess) but  
> SPARC64 integers are 64bits (definitely) and 64bit aligned (guess),  
> and therefore the code to sniffs for the -1 faults. I'm well past  
> this. The fix is simply to mark in Target.m3 procedures as not  
> aligned and then the check for the -1 marker is preceded by a check  
> of the alignment of the pointer, and unaligned pointers are presumed  
> to not be closures.

OK.

> I'd love to be able to say "This area is obviously messed up and it  
> should be done such and such a way.", but the first is true and the  
> second doesn't exist. Oh well.
> My perfectionist and fixy/churny streak can only muster "I wonder  
> how -1 decodes on various architectures and if more reliable per- 
> target markers can be formulated.." esp. something that doesn't  
> depend on invalid encodings, which could be reclaimed in the future  
> for some new instrutions, but perhaps instead relies on valid  
> encodings that would "never" be at the start of a function..though  
> it is pretty hard to rule out anything -- maybe a jmp to 0? I  
> realize that load/store instruction sets can't even necessarily  
> encode that.
> Nope -- x86 encodes jmps as PC-relative.
> Ok -- indirect call:
>
> 7c901230 ff1500000000    call    dword ptr ds:[0]
> 7c901236 0f84c4ed6f83    je      00000000
>
> so ff 15 00 00 00 00 may be a better marker of "not code" than ff ff  
> ff ff, on x86, maybe.
>
> You know -1 may not be legal today, but it could be become legal in  
> the future..
> Whereas *arguably* call indirect 0 is "legal" today, so would not  
> change meaning, but "never" occurs, so could be a marker, for some  
> definition of "legal", "never", etc....
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080527/6f36ce12/attachment-0002.html>