Different sized data and code pointers

Thomas Gill thomas.gill@csr.com
Fri Mar 4 10:53:00 GMT 2005


Julian Brown wrote:

> FWIW, a port I did used indirection for all function pointers, albeit
> for a different reason, and I can report that it seems to work OK in
> practice with a little linker magic. It wasn't really production-quality
> code though, I admit.
> 
> Perhaps the indirection table can safely hold only those functions whose
> address is taken? (Or maybe that was assumed anyway?)

A previous version of our back end did indeed use the indirection (data) 
method, and IIRC only stored pointers for address taken functions. 
However, we really don't have enough data space for that sort of thing. 
Especially since all the developers are used to using a compiler which 
does this `properly'.

Another possibilty that we've discussed is putting an indirection for 
function pointers at <64k in code space (ie, a load and a branch for 
each function).

However, either way requires us to modify all the obscure function 
pointer code in our firmware (eg, functions that get loaded from flash 
memory to ram before they're run) and we've got a hack that *nearly* 
works[1]. It worries me that doing anything other than leaving it alone 
it likely to introduce more bugs than it fixes. In fact I've now patched 
up the slight breakage we were seeing in the hack, so it's even more 
tempting to just leave it alone again.


Ned.


[1] Ok, here's the hack. Get a bucket, you might be sick.
The header in the machine description has something like:
extern tree type, decl;
#define Pmode xap_pmode(type,decl)
#define POINTER_SIZE xap_pointer_size(type,decl)

Those functions check to see if they're looking at the global type and 
decl (which are defined to NULL in the C file), or if there's some other 
type or decl in scope where the macro's used. If one of them is in 
scope, and it's a function pointer type, then they return HImode or 32 
otherwise they return QImode or 16 (yes, QImode - our platform has 16 
bit bytes).

It's possibly the worst hack I've ever had the misfortune to come 
across. I can't imagine how anyone ever thought it was a good idea. The 
worst thing of all it that it actually works quite well and since people 
are already using it, I'm not going to be allowed to get rid of it until 
I come up with something that works equally well :(


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

**********************************************************************



More information about the Gcc mailing list