WINDOWS GCC

[yy172]

When using the Windows version of riscv-none-elf-gcc to compile a project containing Chinese paths, there are both GBK and UTF-8 Chinese encodings in the debug information of the ELF file, causing errors during GDB debugging. Could you please advise whether this is related to the compilation configuration?

[ilg-ul]

Could you please advise whether this is related to the compilation configuration?

Unfortunately I have no experience with non-UTF encodings, so It might be very well a configuration issue, or it might not be supported at all. The compilation configuration generally follows the configuration used by Arm in the arm-none-eabi-gcc toolchain.

Do you know of other toolchain builds that do not have this issue?

[yy172]

Crosstool-NG

[yy172]

I found that xpack-gcc12.2 does not have this issue, but xpack-gcc13 and later versions all have this issue. Is there any change in the compilation configuration？

[ilg-ul]

You mean xPack GNU RISC-V Embedded GCC v12.2.0-3?

Could you also try the official Arm toolchain (https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads)?

It is important to know if the issue is inherited from them or is specific to my scripts.

Is the issue in the compiler that produces wrong binaries, or in the debugger, that does not understand them? So, could you try to compile your files with gcc 12.2 and debug them with the latest 15.2?

Could you also provide a small source file using such a non-UTF encoding, so I can test it on my machines?

[yy172]

When using the ARM toolchain from the link above, there are issues. Debugging files generated by GCC 12.2 with GDB from GCC 15.2 also works without problems. However, when debugging with GDB from GCC 15.2, errors occur during setting breakpoints or retrieving information because there are two different encodings mixed, which causes parsing failures and prevents finding the corresponding locations. This issue can be reproduced simply by naming the source file with Chinese characters from the GBK character set.

[ilg-ul]

naming the source file with Chinese characters from the GBK character set

:-)

My Chinese reading glasses are a bit foggy, and I might not enter the characters correctly. ;-)

So the issue is caused by the file names, wrongly stored in the debug sections of the object files and not interpreted correctly by gdb, right?

We need to isolate the culprit, either the compiler or the debugger.

So if files generated with gcc 12.2 can be debugged with the gdb from 15.2, it looks like the issue is with the 15.2 compiler.

To confirm this, can you try to debug the files generated by 15.2 with the gdb from 12.2? this should fail too.

Another test would be to dump somehow the debug sections of the object files generated by 12.2 and 15.2 and compare the results, more precisely to check if the file names are stored correctly in the files generated by 15.2.