[Bug driver/88262] gcc uses crt1.o in place of Scrt1.o when the main function is in a PIC shared lib

[egeyar.bagcioglu at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88262

--- Comment #20 from Egeyar Bagcioglu  ---
This issue is fixed in gold for binutils 2.33:
https://sourceware.org/bugzilla/show_bug.cgi?id=23870

[Bug driver/88262] gcc uses crt1.o in place of Scrt1.o when the main function is in a PIC shared lib

[stephen.kim at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88262

--- Comment #19 from Stephen Kim  ---
Thank you for all of your comments! I have talked with our team members again. 

It seems that there has been miscommunication. They seemed to have intended
that Go tools should give Scrt1.o. However, as Go tools is just an ordinary
client of gcc (and clang or whatsoever), I believed that Go tools is not
supposed to know about Scrt1.o or crt1.o. They are internals. That made me
think that the gcc driver must be the culprit. 

However, it seems that the gcc driver is supposed to give crt1.o, and I could
now convince myself. 

If that's the case, this issue should be resolved either in glibc or gold.
Thanks again!

[Bug driver/88262] gcc uses crt1.o in place of Scrt1.o when the main function is in a PIC shared lib

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88262

--- Comment #18 from Andrew Pinski  ---
So looking into the gcc's header files, we have the following in gnu-user.h:
  "%{shared:; \
 pg|p|profile:gcrt1.o%s; \
 static:crt1.o%s; \
 " PIE_SPEC ":Scrt1.o%s; \
 :crt1.o%s} \

So every linux target uses crt1.o for non-PIE based executables.

The question I have is why is gold not doing the correct thing for those
relocations; shouldn't behaving the similar ones for other function pointers
loads?

In fact for:
int f(void);

typedef int (*h)(void);

h g(void)
{
  return f;
}

We get:
g:
adrpx0, f
add x0, x0, :lo12:f
ret

Which is exactly what is in start.S and in crt1.o.  So my guess it is a bug in
either how the runtime relocations are incorrectly being created with gold or
being resolved incorrectly inside glibc's ld.so.

Again what happens if you use BFD based ld?  Does it work?  If it does, then
can you look into the difference in the runtime relocations that are being
created?  This is the only thing which would be causing the difference.

Also note all targets have similar code like the above in crt1.o and they all
work so there must be something wrong in either gold creation of runtime
relocations or glibc's resolution of those runtime relocations (all for
AARCH64).

[Bug driver/88262] gcc uses crt1.o in place of Scrt1.o when the main function is in a PIC shared lib

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88262

--- Comment #17 from Andrew Pinski  ---
So the way i read it is crt1.o is still incorrect and not using the got for the
addreas of main. Rather it is assuming it is inside the executable.  Can you
send a line to where the discussion of the glibc qrsh done?  We can try to come
up with if it is a glibc bug or not.  Right now the assembly looks incorrect
for this case. Which makes it a glibc issue rather than gcc issue.

[Bug driver/88262] gcc uses crt1.o in place of Scrt1.o when the main function is in a PIC shared lib

[stephen.kim at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88262

--- Comment #16 from Stephen Kim  ---


(In reply to Andrew Pinski from comment #15)
> Let's start over.  crt1.o in glibc should support calling main that is
> located in the shared library.
> If it does not then there is a bug there.
> 
Sorry. I got notice this comment a bit late. 

Firstly, the glibc commit I posted was not correct. It seems like this commit:
 6cd380dd366d728da9f579eeb9f7f4c47f48e474

It does not. Nonetheless, a glibc maintainer, Siddhesh Poyarekar, told me that
it is NOT a glibc bug. I am not a glibc expert, so I did not find a reason that
I should not believe Siddhesh regarding glibc. 

> Can you explain why you think crt1.o is broken that it can't be used for
> that purpose?
> 
If I manually link with Scrt1.0, it works. I firstly used -Wl,-v option to see
what options are passed to Gold. Then, I just change crt1.o with Scrt1.o, which
works. Running the generate executable does not cause a segmentation fault as
the address of main is correctly found in the _start function. However, I am
not sure whether we could call it "broken crt1.o." The glibc maintainer and
also Ian Lance Taylor--the Gold developer--believed that Scrt1.o should be
given.

> Also you pointed to a commit which you said changed the behavior in glibc
> but the commit you pointed to only changes dates and nothing more.  Can you
> point to the commit which changed the behavior in glibc which caused this
> not to work any more?  
> 

I am not a glibc expert, so I am not sure about the details. I found three
commits that updated start.S probably with regard to my issue.

Here is the commit message:

AArch64: use movz/movk instead of literal pools in start.S

eXecute-Only Memory (XOM) is a protection mechanism against some ROP
attacks. XOM sets the code as executable and unreadable, so the access
to any data, like literal pools, in the code section causes the fault
with XOM. The compiler can disable literal pools for C source files,
but not for assembly files, so I use movz/movk instead of literal pools
in start.S for XOM.

I add MOVL macro with movz/movk instructions like movl pseudo-instruction
in armasm, and use the macro instead of literal pools.

* sysdeps/aarch64/start.S: Use MOVL instead of literal pools.
* sysdeps/aarch64/sysdep.h (MOVL): Add MOVL macro.


Since then, there have been multiple commits that change start.S regarding the
problem:


commit 3d1d79283e6de4f7c434cb67fb53a4fd28359669
Author: Szabolcs Nagy 
Date:   Tue Dec 19 18:43:04 2017 +

aarch64: fix static pie enabled libc when main is in a shared library

In the static pie enabled libc, crt1.o uses the same position independent
code as rcrt1.o and crt1.o is used instead of Scrt1.o when -no-pie
executables are linked.  When main is not defined in the executable, but
in a shared library crt1.o is currently broken, it assumes main is local.
(glibc has a test for this but i missed it in my previous testing.)

To make both rcrt1.o and crt1.o happy with the same code, a wrapper is
introduced around main: with this crt1.o works with extern main symbol
while rcrt1.o does not depend on GOT relocations. (The change only
affects static pie enabled libc. Further simplification of start.S is
possible in the future by using the same approach for Scrt1.o too.)

* aarch64/start.S (_start): Use __wrap_main.
(__wrap_main): New local symbol.


commit 14d886edbd3d80b771e1c42fbd9217f9074de9c6
Author: Szabolcs Nagy 
Date:   Fri Nov 17 10:45:32 2017 +

aarch64: fix start code for static pie

There are three flavors of the crt startup code:

1) crt1.o used for non-pie,
2) Scrt1.o used for dynamic linked pie (dynamic linker relocates),
3) rcrt1.o used for static linked pie (self relocation is needed)

In the --enable-static-pie case crt1.o is built with -DPIC and in case
of static linking it interposes _dl_relocate_static_pie in libc to
avoid self relocation.

Scrt1.o is built with -DPIC -DSHARED and it relies on GOT entries that
the static linker cannot relax and thus need relocation before the
start code is executed, so rcrt1.o needs separate implementation.

This implementation does not work for .text > 4G position independent
executables, which is fine since the toolchain does not support
-mcmodel=large with -fPIE.

Tests pass with ld/22269 and ld/22263 binutils bugs fixed.

* sysdeps/aarch64/start.S (_start): Handle PIC && !SHARED case.

commit 6cd380dd366d728da9f579eeb9f7f4c47f48e474 (thecommit2)
Author: Wang Boshi 
Date:   Fri Sep 15 17:53:23 2017 +0100

AArch64: use movz/movk instead of literal pools in start.S

eXecute-Only Memory (XOM) is a protection mechanism against some ROP
attacks. XOM sets the code as executable and unreadable, so the access
to any data, like literal pools, in the code 

[Bug driver/88262] gcc uses crt1.o in place of Scrt1.o when the main function is in a PIC shared lib

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88262

--- Comment #15 from Andrew Pinski  ---
Let's start over.  crt1.o in glibc should support calling main that is located
in the shared library.
If it does not then there is a bug there.

Can you explain why you think crt1.o is broken that it can't be used for that
purpose?

Also you pointed to a commit which you said changed the behavior in glibc but
the commit you pointed to only changes dates and nothing more.  Can you point
to the commit which changed the behavior in glibc which caused this not to work
any more?  

We can forward from there with those two.

[Bug driver/88262] gcc uses crt1.o in place of Scrt1.o when the main function is in a PIC shared lib

[stephen.kim at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88262

--- Comment #14 from Stephen Kim  ---
(In reply to Andreas Schwab from comment #7)
> If you think you have found a bug in glibc, then this is not the right place
> to report it.

I believe that this is NOT a glibc bug. It is TRIGGERED by a glibc patch. I
would say that the glibc patch is legitimate. Personally, I believe that this
is a compiler driver bug. That's why I am filing the bug here. Even now, I am
not convinced that this is not a gcc bug.(In reply to Andrew Pinski from
comment #10)
> This could also be a gold linker issue too.
> 
> But then again this is not the right place to report a gold or glibc issue. 
> Try https://sourceware.org/bugzilla/ instead.

Regarding Gold, I have talked with Ian Lance Taylor, who is known to be an
author of gold and who I believe is a linker expert. He does not think that
this bug is a Gold issue. According to his emails, he seems to believe that
Gold should be given Scrt1.o.

[Bug driver/88262] gcc uses crt1.o in place of Scrt1.o when the main function is in a PIC shared lib

[stephen.kim at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88262

--- Comment #13 from Stephen Kim  ---
(In reply to Andreas Schwab from comment #7)
> If you think you have found a bug in glibc, then this is not the right place
> to report it.

I believe that this is NOT a glibc bug. It is TRIGGERED by a glibc patch. I
would say that the glibc patch is legitimate. Personally, I believe that this
is a compiler driver bug. That's why I am filing the bug here. Even now, I am
not convinced that this is not a gcc bug.

[Bug driver/88262] gcc uses crt1.o in place of Scrt1.o when the main function is in a PIC shared lib

[stephen.kim at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88262

--- Comment #12 from Stephen Kim  ---
(In reply to jos...@codesourcery.com from comment #8)
> On Fri, 30 Nov 2018, stephen.kim at oracle dot com wrote:
> 
> > The glibc commit that triggered this bug is:
> >  bfff8b1becd7d01c074177df7196ab327cd8c844 
> 
> That's the copyright date updates for 2017.

Thank you for the information. Anyway, the patch is still in glibc, and it is
particularly for aarch64. If the bug wasn't reproduced on a system such as
Gentoo, Debian, etc, it is due to either of the following two:
  1. gcc is configured with --enable-default-pie (e.g. Debian, Gentoo)
  2. glibc is old and the patch hasn't been backported (e.g. old Oracle Linux)

[Bug driver/88262] gcc uses crt1.o in place of Scrt1.o when the main function is in a PIC shared lib

[stephen.kim at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88262

--- Comment #11 from Stephen Kim  ---
(In reply to Andrew Pinski from comment #9)
> (In reply to jos...@codesourcery.com from comment #8)
> > On Fri, 30 Nov 2018, stephen.kim at oracle dot com wrote:
> > 
> > > The glibc commit that triggered this bug is:
> > >  bfff8b1becd7d01c074177df7196ab327cd8c844 
> > 
> > That's the copyright date updates for 2017.
> 
> I was going to say that too.
> Maybe:
> https://sourceware.org/git/?p=glibc.git;a=commit;
> h=14d886edbd3d80b771e1c42fbd9217f9074de9c6

It does not seem to be the fix for this one I had been reporting. (In reply to
Andrew Pinski from comment #9)
> (In reply to jos...@codesourcery.com from comment #8)
> > On Fri, 30 Nov 2018, stephen.kim at oracle dot com wrote:
> > 
> > > The glibc commit that triggered this bug is:
> > >  bfff8b1becd7d01c074177df7196ab327cd8c844 
> > 
> > That's the copyright date updates for 2017.
> 
> I was going to say that too.
> Maybe:
> https://sourceware.org/git/?p=glibc.git;a=commit;
> h=14d886edbd3d80b771e1c42fbd9217f9074de9c6


Thank you for sharing the link. The bug here I am reporting is !PIC case. The
fix is for PIC && !SHARED case.

[Bug driver/88262] gcc uses crt1.o in place of Scrt1.o when the main function is in a PIC shared lib

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88262

--- Comment #10 from Andrew Pinski  ---
This could also be a gold linker issue too.

But then again this is not the right place to report a gold or glibc issue. 
Try https://sourceware.org/bugzilla/ instead.

[Bug driver/88262] gcc uses crt1.o in place of Scrt1.o when the main function is in a PIC shared lib

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88262

Andrew Pinski  changed:

   What|Removed |Added

 Target||aarch64-*-linux-gnu
 CC||pinskia at gcc dot gnu.org

--- Comment #9 from Andrew Pinski  ---
(In reply to jos...@codesourcery.com from comment #8)
> On Fri, 30 Nov 2018, stephen.kim at oracle dot com wrote:
> 
> > The glibc commit that triggered this bug is:
> >  bfff8b1becd7d01c074177df7196ab327cd8c844 
> 
> That's the copyright date updates for 2017.

I was going to say that too.
Maybe:
https://sourceware.org/git/?p=glibc.git;a=commit;h=14d886edbd3d80b771e1c42fbd9217f9074de9c6

[Bug driver/88262] gcc uses crt1.o in place of Scrt1.o when the main function is in a PIC shared lib

[joseph at codesourcery dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88262

--- Comment #8 from joseph at codesourcery dot com  ---
On Fri, 30 Nov 2018, stephen.kim at oracle dot com wrote:

> The glibc commit that triggered this bug is:
>  bfff8b1becd7d01c074177df7196ab327cd8c844 

That's the copyright date updates for 2017.

[Bug driver/88262] gcc uses crt1.o in place of Scrt1.o when the main function is in a PIC shared lib

[sch...@linux-m68k.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88262

Andreas Schwab  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #7 from Andreas Schwab  ---
If you think you have found a bug in glibc, then this is not the right place to
report it.

[Bug driver/88262] gcc uses crt1.o in place of Scrt1.o when the main function is in a PIC shared lib

[stephen.kim at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88262

Stephen Kim  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |---

--- Comment #6 from Stephen Kim  ---
This bug is reproducible only on arm64. Sorry for missing the info. That was my
bad. 

Besides, it is reproducible with a particular patch in glibc, which was made
this year. 

And, the reason that glibc test did not detect this issue is because Debian gcc
seems to default pie. I.e. it might be configured with --enable-default-pie.
Gentoo does the same. Thus, they are giving Scrt1.o.

As of today, the gcc I got after running Debian:latest docker container and
executing "apt-get update," shows this on "gcc -v":
 $ gcc -v  2>&1 | egrep -o "enable-default-pie"
 enable-default-pie

Oracle Linux on arm64 is the environment that meets the requirements for the
bug. It has the glibc patch, and the gcc is not configured to default PIE. 

Thus, if not being reproducible was the reason that the bug is closed, I would
say that it is reproducible. Please, use oraclelinux:latest docker container on
aarch64.

If this bug is closed because it is indeed user's fault not a compiler driver
error, please, close this bug again.

[Bug driver/88262] gcc uses crt1.o in place of Scrt1.o when the main function is in a PIC shared lib

[stephen.kim at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88262

--- Comment #5 from Stephen Kim  ---
(In reply to jos...@codesourcery.com from comment #3)
> As of October 2017, glibc has a testcase that having main in a shared 
> library works - that's a valid use case, which should work with crt1.o.  
> If it doesn't work for some particular architecture that would be a glibc 
> bug (or conceivably an ld bug) - but I'd also expect it to show up as a 
> failure of the glibc elf/tst-main1 test, and no such failure is listed for 
> any architecture on .

It is reproducible, currently with Oracle Linux. For example, you could do:
 docker run -it oraclelinux:7.5 /bin/bash

followed by:
  yum update -y

Then, the issue is reproducible. I think I am the one that discovered this
issue while building Go tools on aarch64.

[Bug driver/88262] gcc uses crt1.o in place of Scrt1.o when the main function is in a PIC shared lib

[stephen.kim at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88262

Stephen Kim  changed:

   What|Removed |Added

 CC||stephen.kim at oracle dot com

--- Comment #4 from Stephen Kim  ---


(In reply to jos...@codesourcery.com from comment #3)
> As of October 2017, glibc has a testcase that having main in a shared 
> library works - that's a valid use case, which should work with crt1.o.  
> If it doesn't work for some particular architecture that would be a glibc 
> bug (or conceivably an ld bug) - but I'd also expect it to show up as a 
> failure of the glibc elf/tst-main1 test, and no such failure is listed for 
> any architecture on .

The glibc commit that triggered this bug is:
 bfff8b1becd7d01c074177df7196ab327cd8c844 

It is a patch for aarch64 only. From there, giving crt1.o rather than Scrt1.o
has become problematic. 

The patch is included in Oracle Linux while it is not in Debian. The patch was
made this year. Thus, back then 2017, I think this problem did not exist.
Unfortunately, glibc still keeps the patch. Thus, the bug might be going to be
a problem in case of other Linux distro running on arm64, I believe. Gentoo has
the same issue but it avoids by defaulting PIE: --enable-default-pie at
configure.

[Bug driver/88262] gcc uses crt1.o in place of Scrt1.o when the main function is in a PIC shared lib

[joseph at codesourcery dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88262

--- Comment #3 from joseph at codesourcery dot com  ---
As of October 2017, glibc has a testcase that having main in a shared 
library works - that's a valid use case, which should work with crt1.o.  
If it doesn't work for some particular architecture that would be a glibc 
bug (or conceivably an ld bug) - but I'd also expect it to show up as a 
failure of the glibc elf/tst-main1 test, and no such failure is listed for 
any architecture on .

[Bug driver/88262] gcc uses crt1.o in place of Scrt1.o when the main function is in a PIC shared lib

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88262

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Richard Biener  ---
I think this is a user error indeed.

[Bug driver/88262] gcc uses crt1.o in place of Scrt1.o when the main function is in a PIC shared lib

[sch...@linux-m68k.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88262

--- Comment #1 from Andreas Schwab  ---
>From the gcc driver's point of view this is just a normal link since it does
not know where main is defined.