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

[Tom Roeder]

On Wed, May 21, 2014 at 12:19 PM, Tom Roeder <tmroeder at google.com> wrote:
> On Wed, May 21, 2014 at 12:01 PM, Rafael Espíndola
> <rafael.espindola at gmail.com> wrote:
>>> Not quite. The jumptable code creates a declaration (but not a
>>> definition) that will later be satisfied by generated assembly in
>>> AsmPrinter. It then goes and replaces all address-taken uses of the
>>> function symbol with the declaration. So, the problem happens when
>>> there's a statement like
>>>
>>> @falias = alias i32 ()* @f
>>>
>>> where @f has the jumptable attribute and is being replaced with a
>>> declared but not defined function, say @f_JT. Ideally, I'd just be
>>> able to replace @f with @f_JT, but since there's no definition for
>>> @f_JT, the GlobalAlias code balks, for good reasons, as you explained.
>>>
>>> It happens that this declaration in this case is going to resolve into
>>> a real symbol in the same asm file, but there's no way the code can
>>> tell that.
>>
>> This seems like a representation issue. Can't you create a fake global
>> variable (like llvm.used for example) that during codegen gets
>> converted in the same way the declaration is currently?
>
> Do you mean: store the names of the functions that need to be replaced
> and don't replace them until they need to be written out?
>
> The problem I see in that suggestion is that we don't want to replace
> direct calls to the function, only addr-taken uses. So, there need to
> be two ways to call each jumptable function: direct calls through the
> original symbol and indirect calls through the jumptable symbol.
>
> Also, my work on control-flow integrity that works over jump tables
> must know all the replacement symbols to do its job, since it uses
> these symbols to generate the check code it inserts at each indirect
> call site. So, either there needs to be replacement symbols for it to
> use, or everything has to go down into AsmPrinter. The latter options
> seems to me like a lot of unnecessary complexity, since function
> replacement is very natural and easy in IR.

Oh wait. Another way of interpreting your suggestion is to make a list
of GlobalAliases to replace and only do the replacement at the end,
when there's actually a symbol to use. Yes, I think that could be made
to work. I'll look into it.