Question related to GCC structure variable assignment optimization

[keshav tilak]

I need some help for GCC optimization behavior which inserts call to
`memcpy` when
it detects that there is a structure variable assignment.

I have below sample code (copied from a similar gcc-help question):

[  0] [15:21:40] root@localhost : # cat b.c
struct foo_t {
int x[1048576];
} *foo0, *foo1;

void bar(struct foo_t* foo)
{
*foo1 = *foo;
}

int main()
{
return 0;
}

# /usr/src/gcc-6.1.0/build/bin/gcc -fPIE -S b.c

This leads to GCC compiler issuing a call to `memcpy@PLT()' in function bar1.

I want to create a position independent executable from this source
and run this on
a secure environment which implements ASLR and the loader disallows any binary
which has PLT/GOT based relocations.

I have tried with option `-fno-tree-loop-distribute-patterns' but even
with this option,
if `-fPIE' flag is present I see that there is reference to `memcpy@PLT'.

I have even tried options like `-fno-plt' and
`-mstringop-strategy=loop' but I do not want
to use the output program generated with these options.

My problem is not with memcpy but with PLT portion; I want GCC to
generate reference
to `memcpy' (and not to `memcpy@PLT') in a position independent
executable when it
detects that there is structure variable assignment.

I have also tried by putting hidden visibility for this file but there
is same PLT
reference in this case also.
#pragma GCC visibility push(hidden)

Does GCC always insert call to `memcpy@PLT' for position independent
executables when
it detects that there is a structure variable assignment?

Is it possible to instruct GCC to insert `memcpy' with -fPIE flag for
structure variable assignments?

- GampuZ

Re: Question related to GCC structure variable assignment optimization

[keshav tilak]

 >> Are you sure the linker does not perform this relaxation in your case?
If so,
>> that's an issue (missed optimization) in the linker.
yes, after linking phase also I see reference memcpy from PLT.

The file I am building is created with -ffreestanding and -fnostdlib
option; The memcpy function
is provided in a different source file; The memcpy optimization is
generated for a different source file. I am
compiling all files with hidden visibility via the pragma declarative.
After this I am linking the files using ld. After
ld phase, I see that the final output binary is having references to PLT
only in file which has structure pointer
assignment. Nowhere else PLT reference is seen.

>> (re)declaring memcpy with hidden visibility
This method also does not work in my case. I am still seeing PLT
relocations in my output file.

In this case, if I am getting a memcpy@PLT reference then this bug should
be similar to the one you
pointer in earlier email, right? (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86695)

- KGT

- Keshav Gangadhar Tilak


On Fri, Jul 27, 2018 at 2:24 PM Alexander Monakov 
wrote:

> On Fri, 27 Jul 2018, keshav tilak wrote:
> > This leads to GCC compiler issuing a call to `memcpy@PLT()' in function
> bar1.
> >
> > I want to create a position independent executable from this source
> > and run this on
> > a secure environment which implements ASLR and the loader disallows any
> binary
> > which has PLT/GOT based relocations.
>
> The linker should be able to relax those nominally-PLT calls to direct
> calls
> since it emits a PIE and a local definition is available. Therefore the
> loader
> (the dynamic linker) should not get a GOT relocation for this call.
>
> Are you sure the linker does not perform this relaxation in your case? If
> so,
> that's an issue (missed optimization) in the linker.
>
> That said, the GCC should be able to emit direct calls as in some cases,
> most
> notably the 32-bit x86 ABI, it causes a size/speed penalty the linker would
> not be able to clean up.
>
> What should work is (re)declaring memcpy with hidden visibility:
>
>   __attribute__((visibility("hidden")))
>   void *memcpy(void *, const void *, size_t);
>
> or via the pragma, but today this doesn't work. I've opened a GCC bugreport
> for this: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86695
>
> Alexander
>