This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v5 00/14] port C-SKY to glibc
On Mon, 26 Nov 2018, Mao Han wrote:
> We'v tried to remove this condition, but seems doesn't meet our expectation.
> The ia64 case seems only get a test need to run on the target, return -1 when
> init_array is not support. I didn't found any AC_RUN_IFELSE in current gcc 9.0
> gcc/configure. The *) case seems can return gcc_cv_initfini_array=yes
> on C-SKY target, but it only check whether tools can generate init_array
> section, not libc use init_array or not.
Yes, that's right. init_array is a standard feature of ELF and has been
for a very long time. So it's entirely correct that GCC should default to
using it unless it knows there's a problem with support for that feature
on some platform, and the present restriction to native builds is wrong.
It's true that removing the restriction to native builds might help show
up places where libc is missing init_array support. If it does, we can
then consider whether some more selective disabling on those platforms
would be appropriate - but enabling by default for ELF platforms,
independent of whether native, is still the right thing to do.
> PASS: compilers-mips64-linux-gnu-soft glibc mips64-linux-gnu-n64-soft copy
> *** Error in `/home/vmh/disk2/buildmany/install/compilers/mips64-linux-gnu-soft/lib/gcc/mips64-glibc-linux-gnu/9.0.0/../../../../mips64-glibc-linux-gnu/bin/ld': free(): invalid next size (fast): 0x000000000250c100 ***
> ======= Backtrace: =========
> /lib/x86_64-linux-gnu/libc.so.6(+0x777e5)[0x7f45a2d417e5]
> /lib/x86_64-linux-gnu/libc.so.6(+0x8037a)[0x7f45a2d4a37a]
> /lib/x86_64-linux-gnu/libc.so.6(cfree+0x4c)[0x7f45a2d4e53c]
> /home/vmh/disk2/buildmany/install/compilers/mips64-linux-gnu-soft/lib/gcc/mips64-glibc-linux-gnu/9.0.0/../../../../mips64-glibc-linux-gnu/bin/ld[0x4440c0]
> /home/vmh/disk2/buildmany/install/compilers/mips64-linux-gnu-soft/lib/gcc/mips64-glibc-linux-gnu/9.0.0/../../../../mips64-glibc-linux-gnu/bin/ld[0x4926bf]
> /home/vmh/disk2/buildmany/install/compilers/mips64-linux-gnu-soft/lib/gcc/mips64-glibc-linux-gnu/9.0.0/../../../../mips64-glibc-linux-gnu/bin/ld[0x467c22]
> ...
> PASS: compilers-mips64-linux-gnu-nan2008-soft glibc mips64-linux-gnu-n64-nan2008-soft configure
>
> The final result is PASS. I haven't found the rootcause yet.
That's a known (i.e. observed for years) linker bug, though I've no idea
where the underlying cause is in binutils.
> I used __cp_stat_statx in the last patch, the high part will cut off when
> assign a 64bit variable to a 32bit one. The padding seems will never become
> non-zero, so I didn't use stat_overflow in last patch. In order to return
> whether st_ino, st_size, st_blocks are overflowed, the high part should
> be keeped or some check is needed on statx result? So make the callers
> cast to (struct stat64 *) and call __cp_stat64_statx will make the funcion
> behavior exactly same as the old one?
Yes, that's my suggestion. Silent truncation is not acceptable; if
truncation occurs, it is required to produce an EOVERFLOW error, and it
seems best to arrange things so that the existing overflow check code can
be used for that.
--
Joseph S. Myers
joseph@codesourcery.com