[PATCH] Add an option to allow JumpInstrTables to set unnamed_addr and jumptable on all address-taken functions

[Nick Lewycky]

Tom Roeder wrote:
> On Tue, Jun 24, 2014 at 12:00 PM, Tom Roeder<tmroeder at google.com>  wrote:
>> On Mon, Jun 23, 2014 at 12:18 PM, Nick Lewycky<nicholas at mxc.ca>  wrote:
>>> Tom Roeder wrote:
>>>> I don't see why this should have anything to do with a front end
>>>> component, though it might make sense eventually to have a high-level
>>>> flag like that in clang that sets a lower-level flag. Currently, I
>>>> just pass flags directly to LTO through clang with
>>>>
>>>> -Wl,--plugin-opt=-jump-table-type=arity
>>>
>>>
>>> Mostly I want to have a single place to decide whether we're going to do the
>>> jump table transform or not. The reason it goes in the frontend is because
>>> it actually changes language semantics, the frontend may want to emit
>>> different IR, or may want to warn the user that "&func1 == my_funcptr" isn't
>>> going to work when CFI is on. If you did have it in the frontend, I don't
>>> see why you would also need a plugin option.
>>
>> That makes sense; I'll look into it.
>
> It looks fairly straightfoward to add the option in clang; however,
> after thinking about it some more, I think that even with a frontend
> option, there still needs to be a way to trigger CFI from the back end
> directly, since there needs to be some way to write CFI regression
> tests in LLVM directly without using clang.

Sure. For LLVM you can write a .ll file and observe the .s llc emits, 
and you can write a .ll file and run any pass over it and observe the 
resulting .ll. I think you just need to write .ll files with 
unnamed_addr jumptable on the functions then observe the .s files, I 
don't think you have a use for opt tests? For clang you can write a test 
that you get the .ll you expect for a given .c file.

That's the common way of testing llvm and clang. You can write arbitrary 
shell to do things like llvm-link + opt + llc in a test if you want, but 
I don't think you should ever need that?

I think all your use cases covered by this? If not, which?

Nick