This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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/[0x7f45a2d417e5]
> /lib/x86_64-linux-gnu/[0x7f45a2d4a37a]
> /lib/x86_64-linux-gnu/[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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]