Re: Broken RISC-V code in newlib

On 3/25/25 12:01 PM, Jeff Law wrote:
> On 3/25/25 9:19 AM, Eric Salem wrote:
>> On 3/25/25 10:14 AM, Kito Cheng wrote:
>>> BTW, I can reproduce those build issue on my clean build as well
>>
>> Are there any sort of flags you set for your build? I build a stock Newlib
>> library but I still can't get the build to break for me. I'm wondering how
>> it knows to use the port specific includes when <> is used to include the
>> header file for my build and not yours.
> Nothing particularly special.
> 
> You may be running into headers being pulled out of a pre-existing install directory or something along those lines.
> 
> You can add "-save-temps" to gcc invocation which will save the .i (cpp output).  Within the .i file you can look at the line markers to tell you what files where used to satisfy any particular #include.  It's painful, but works.
> 
> Or you can add "-v" to a gcc invocation to print the command line as well as various internal information:
> 
>> jlaw@k1:~$ gcc -v j.c
>> Using built-in specs.
>> COLLECT_GCC=gcc
>> COLLECT_LTO_WRAPPER=/usr/libexec/gcc/riscv64-linux-gnu/14/lto-wrapper
>> Target: riscv64-linux-gnu
>> Configured with: ../src/configure -v --with-pkgversion='Debian 14.2.0-17' --with-bugurl=file:///usr/share/doc/gcc-14/README.Bugs --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2,rust --prefix=/usr --with-gcc-major-version-only --program-suffix=-14 --program-prefix=riscv64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/libexec --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-libstdcxx-backtrace --enable-gnu-unique-object --disable-libquadmath --disable-libquadmath-support --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=a
 uto --enable-multiarch --disable-werror --disable-multilib --with-arch=rv64gc --with-abi=lp64d --enable-checking=release --build=riscv64-linux-gnu --host=riscv64-linux-gnu --target=riscv64-
>> linux-gnu --with-build-config=bootstrap-lto-lean --enable-link-serialization=2
>> Thread model: posix
>> Supported LTO compression algorithms: zlib zstd
>> gcc version 14.2.0 (Debian 14.2.0-17) COLLECT_GCC_OPTIONS='-v' '-march=rv64imafdc_zicsr_zifencei' '-mabi=lp64d' '-misa-spec=20191213' '-mtls-dialect=trad' '-march=rv64imafdc_zicsr_zifencei' '-dumpdir' 'a-'
>>  /usr/libexec/gcc/riscv64-linux-gnu/14/cc1 -quiet -v -imultilib . -imultiarch riscv64-linux-gnu j.c -quiet -dumpdir a- -dumpbase j.c -dumpbase-ext .c -march=rv64imafdc_zicsr_zifencei -mabi=lp64d -misa-spec=20191213 -mtls-dialect=trad -march=rv64imafdc_zicsr_zifencei -version -o /tmp/ccAChyBE.s
>> GNU C17 (Debian 14.2.0-17) version 14.2.0 (riscv64-linux-gnu)
>>         compiled by GNU C version 14.2.0, GMP version 6.3.0, MPFR version 4.2.1, MPC version 1.3.1, isl version isl-0.26-GMP
>>
>> GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
>> ignoring nonexistent directory "/usr/local/include/riscv64-linux-gnu"
>> ignoring nonexistent directory "/usr/lib/gcc/riscv64-linux-gnu/14/include-fixed/riscv64-linux-gnu"
>> ignoring nonexistent directory "/usr/lib/gcc/riscv64-linux-gnu/14/include-fixed"
>> ignoring nonexistent directory "/usr/lib/gcc/riscv64-linux-gnu/14/../../../../riscv64-linux-gnu/include"
>> #include "..." search starts here:
>> #include <...> search starts here:
>>  /usr/lib/gcc/riscv64-linux-gnu/14/include
>>  /usr/local/include
>>  /usr/include/riscv64-linux-gnu
>>  /usr/include
>> End of search list.
> 
> 
> Note the last few lines.  Those show the search paths for <> includes. Obviously you'd need to add this to the line used when building the problematic file in newlib.
> 
> Jeff
> 
> ps.  And to be clear, the output above is on a native riscv64 system, not a cross :-)  I just wanted to show you that "-v" might help answer your question.

Thank you, Jeff. I was finally able to figure out what's happening with
your help. I generated the intermediate files and you weren't kidding.
Pretty awful to dig through. But I could see the sys/string.h header
file from the RISC-V port being included, which explains why I didn't
get any errors. But I couldn't understand why it was working.

With the -v option, when compiling C files I could see that the first
two paths gcc searched for were in the Newlib project:

 newlib/build/targ-include
 newlib/libc/include

During the build, Newlib must be making a copy of the various header
files and copying them to the first directory. But the relevant file
for the port is in sys/string.h, and only string.h is being included,
so how was the port's header file getting included?

In the second directory, string.h exists. And within that file, there's
this line:

#include <sys/string.h>

This path does exist in targ-include, and so that file is found and
included. That explains why I didn't get any errors for the C files.

But that doesn't explain why the assembly files worked for me. strcmp.S
contains this line:

#include <sys/asm.h>

So it should've failed for me. But it didn't because the include paths
for header files when the assembler runs don't list the two
aforementioned paths, which is why I didn't get any errors.

Now I get why you initially thought it's like no one even tested those
changes. I can assure you I did, but because of the include paths that
Newlib used (or didn't use) when building, that hid the error. It makes
me wonder why Newlib is including those paths for me but not for others
on a fresh clone and build. Either way, using "" instead of <>,
prefixing the path with "sys/", and moving the typedef to another header
file works for everyone, so that's the best solution.

Thanks again for your help.

Eric