https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98784
--- 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 access > > it or something along this line. > > I misremembered: the code loading the GOT register is eliminated if not used > in the end, but it can block the leaf register optimization, i.e. a register > 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/sparc/sysdep.h?id=ab1dd83bec59c9e65c31efd6e887182948f627be https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/sparc/sysdep.h;h=31a8addebcbeec2f60ece377677bc2be137b3664;hb=d811d240c06a8191db88ad4f1e60e1b672e4cc66 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 sparc 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
