From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
 id D1299385141F; Tue, 26 Jan 2021 22:29:08 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D1299385141F
From: "romain.naour at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/98784] [8/9/10/11 Regression] problematic build of
 uClibc with -fPIC
Date: Tue, 26 Jan 2021 22:29:08 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 10.2.0
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: romain.naour at gmail dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 8.5
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-98784-4-4C3Tf4CRI3@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-98784-4@http.gcc.gnu.org/bugzilla/>
References: <bug-98784-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: gcc-bugs@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-bugs mailing list <gcc-bugs.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Jan 2021 22:29:08 -0000

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

--- Comment #10 from Romain Naour <romain.naour at gmail dot com> ---
(In reply to Eric Botcazou from comment #8)
> > OK, this makes sense now and this looks like a bootstrap problem, e.g. =
the
> > code setting up _GLOBAL_OFFSET_TABLE_ in the libc might be trying to ac=
cess
> > it or something along this line.
>=20
> I misremembered: the code loading the GOT register is eliminated if not u=
sed
> in the end, but it can block the leaf register optimization, i.e. a regis=
ter
> window is allocated although it is not needed.  So does uClibc depend on =
the
> fact that a register window is not allocated in some specific spot?

Since some part of uClibc code come from glibc, I'm trying to compare with
glibc 2.30... but there are some differences.

For example there is no SETUP_PIC_REG_LEAF definition for sparc32 in uClubc:
(SETUP_PIC_REG_LEAF use internally _GLOBAL_OFFSET_TABLE_)

https://cgit.uclibc-ng.org/cgi/cgit/uclibc-ng.git/tree/libc/sysdeps/linux/s=
parc/sysdep.h?id=3Dab1dd83bec59c9e65c31efd6e887182948f627be

https://sourceware.org/git/?p=3Dglibc.git;a=3Dblob;f=3Dsysdeps/sparc/sysdep=
.h;h=3D31a8addebcbeec2f60ece377677bc2be137b3664;hb=3Dd811d240c06a8191db88ad=
4f1e60e1b672e4cc66

The uClibc code doesn't seems up-to-date with the glibc version...
But I can't try to reproduce the issue with glibc since the support for spa=
rc
has been removed from Buildroot since a long time and from glibc for sparcv8
since 2.31: https://lwn.net/Articles/811275/

resync the sparc port for uclibc with glibc requires a lot of work.

Best regards,
Romain=