On Fri, Jan 30, 2015 at 6:12 AM, Alan Modra <amo...@gmail.com> wrote:
> On Fri, Jan 30, 2015 at 01:19:51PM +1030, Alan Modra wrote:
>> On Thu, Jan 29, 2015 at 04:21:15PM +0100, Richard Biener wrote:
>> > > This means that you still will be able to create a testcase that is
>> > > miscompiled with exposing the address-taking to points-to analysis.
>>
>> I'm sorry, I don't see how to. (I'm not disagreeing, just ignorant.)
>
> Sigh. Yes, I can make such a testcase.
>
> typedef struct {
> unsigned long fd_func;
> unsigned long fd_toc;
> unsigned long fd_aux;
> } Elf64_FuncDesc;
>
> int a, b;
>
> int
> foo (__attribute__((const)) int (*f) (int), long adjust)
> {
> Elf64_FuncDesc opd;
>
> a = 1;
> b = 2;
> if (adjust)
> {
> opd = *(Elf64_FuncDesc *) f;
> opd.fd_func += adjust;
> f = (int (*) (int)) &opd;
> }
> int c = f (3);
> a = 3;
> b = 4;
> return c;
> }
>
> This time we lose in .032t.cddce1.
Ok - without digging into why the above would fail with your patch
(don't see that - the use in the function call can't be &opdd) - let's
take a step back and decide whether we want to allow user-created
function descriptors. And if we do that if we should rather expose
this in a more sensible way to GCC, like with using a (target) builtin.
Say, force you to do
int (*f) (int) = __builtin_fdesc (opd.fd_func, opd.fd_toc, opd.fd_aux);
return f (3);
which would allow GCC to even optimize the call to a direct one
if it (or the target) can fold reads from the __builtin_fdesc argument
to a function decl. Similar builtins could allow you to inspect
a function descriptor. That way the actual memory operations
would be hidden from the middle-end.
For glibc you have to workaround the GCC "bug" anyway and I
think people building function descriptors themselves is a very
rare thing... (I don't understand why a function descriptor is not
readily availabe here anyway...)
Thanks,
Richard.
> --
> Alan Modra
> Australia Development Lab, IBM
