[PATCH] Add a jumptable attribute and support for creating jump-instruction tables

[Tom Roeder]

On Wed, May 21, 2014 at 3:42 PM, Rafael Espíndola
<rafael.espindola at gmail.com> wrote:
>> Right. Any code that assumes pointer equality between modules for a
>> function declared as jumptable in both modules will fail.  Now that I
>> think about it, this is true even without putting jumptable into two
>> separate modules, and without adding jumptable to external functions.
>>
>> For example, consider two modules: module M1 declares @f as a normal
>> undefined function, and module M2 defines @f as jumptable. If M2
>> passes a function pointer for @f to M1, it will pass @f_JT. @f_JT will
>> still work perfectly as a function pointer for @f except it will
>> happen not to have the same function pointer value as @f. So, equality
>> comparisons with @f will fail.
>>
>> Is this OK?
>
> At the llvm level such a transformation would only be valid if the
> function was marked with unnamed_addr. You should probably check for
> that and have a clang option that adds unnamed_addr to every function.

I'm not sure what "check for that" means in this case. In my example,
the declaration of @f in M1 would need to be marked unnamed_addr based
on whether or not M2 had a definition @f with jumptable, and that's
something that's not known when M1 is compiled.

It wouldn't be hard to add a clang option to do this, but even that's
technically not sufficient, since it could still cause problems with
modules compiled without the flag or compiled with a different
compiler. I think this shows that jumptable really does affect the
ABI, like Nick suggested. I don't know if this kind of pointer
equality is formally guaranteed at that level, however. Do you know?

AFAICT, this is equivalent to marking a function as unnamed_addr, then
passing its function pointer out to external code. That compiles in
IR, though I don't know if that's a bug or not, since it depends on
the answer to my ABI question. :)

Thanks,

Tom