Re: [RFC] PR64703, glibc sysdeps/powerpc/powerpc64/dl-machine.h miscompile

[Richard Biener <richard dot guenther at gmail dot com>]

On Fri, Jan 30, 2015 at 6:12 AM, Alan Modra <amodra@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