Electronics > Microcontrollers

RISC-V Compiling and Debugging

(1/4) > >>

GromBeestje:
I'm having some issues when debugging a firmware running on a RISC-V microcontroller  (GigaDevice GD32VF103 or WinChipHead CH32V103)
When the code is compiled with a GCC 8 Compiler (binary fromMounRiver's toolchain), all debugging appears to work as expected.
However, when I compile my code with a GCC 12 Compiler (binary xPack toolchain), even though the firmware appears to operate fine, when debugging, GDB acts like the stack is corrupted.

A working firmware compiled with GCC 8 gives the following backtrace.

--- Code: ---(gdb) bt
#0  u8g2_font_decode_len (u8g2=0x20000014 <m_u8g2>, len=0 '\000', is_foreground=0 '\000') at ../../..//ext/u8g2/csrc/u8g2_font.c:400
#1  0x00006078 in u8g2_font_decode_glyph (u8g2=0x20000014 <m_u8g2>,
    glyph_data=0x9f6f <u8g2_font_5x8_tf+399> "\263b\263bkJ\n4b73\310 \225\021K\t4b\023U\222\251\063L\f4b\223A\006\031d\220\301\bM\t4b\023\307", <incomplete sequence \315>)
    at ../../..//ext/u8g2/csrc/u8g2_font.c:605
#2  0x000062aa in u8g2_font_draw_glyph (u8g2=0x20000014 <m_u8g2>, x=15 '\017', y=16 '\020', encoding=73) at ../../..//ext/u8g2/csrc/u8g2_font.c:724
#3  0x0000638c in u8g2_DrawGlyph (u8g2=0x20000014 <m_u8g2>, x=15 '\017', y=16 '\020', encoding=73) at ../../..//ext/u8g2/csrc/u8g2_font.c:789
#4  0x00006418 in u8g2_draw_string (u8g2=0x20000014 <m_u8g2>, x=15 '\017', y=16 '\020', str=0x9ae0 "²C DEMO") at ../../..//ext/u8g2/csrc/u8g2_font.c:807
#5  0x000064ec in u8g2_DrawUTF8 (u8g2=0x20000014 <m_u8g2>, x=0 '\000', y=16 '\020', str=0x9adc "   I²C DEMO") at ../../..//ext/u8g2/csrc/u8g2_font.c:861
#6  0x00001074 in print (str=0x9adc "   I²C DEMO", line=1) at dis2.c:50
#7  0x00000366 in main () at main.c:174

--- End code ---

A working firmware compiled with GCC 12 gives the following backtrace.

--- Code: ---(gdb) bt
#0  u8g2_font_decode_len (u8g2=0x2000006c <m_u8g2+88>, len=4 '\004', is_foreground=0 '\000') at ../../..//ext/u8g2/csrc/u8g2_font.c:400
#1  0x000060ba in u8g2_font_decode_glyph (u8g2=0x2000006c <m_u8g2+88>, glyph_data=0x4004db0 '\377' <repeats 200 times>...) at ../../..//ext/u8g2/csrc/u8g2_font.c:605
Backtrace stopped: frame did not save the PC
(gdb)

--- End code ---

As the firmware compiled with GCC 12 appears to work fine, it is my assumption GDB has troubles interpreting the stack, rather then the stack actually being corrupted. One note regarding the elf files generated by the toolchains, it appears the GCC8 version does not contain architecture specific information, while the GCC12 version does contain architecture specific information, stating the stack alignment is 16 byte.


--- Code: ---$ readelf -A mounriver-studio-toolchain-riscv/i2c_demo.elf

$ readelf -A riscv-none-elf/i2c_demo.elf
Attribute Section: riscv
File Attributes
  Tag_RISCV_stack_align: 16-bytes
  Tag_RISCV_arch: "rv32i2p1_m2p0_a2p1_c2p0"
  Tag_RISCV_priv_spec: 1
  Tag_RISCV_priv_spec_minor: 11

--- End code ---

Could this possibly be the cause of these debugging issues? Do I have to give GDB extra commands for it to work? Or should I pass some more flags to GCC? Or adjust my LD script?

I have uploaded the binaries and map files for these http://www.blaatschaap.be/tmp/tests/

GromBeestje:
I have removed the architecture specific info


--- Code: ---$ riscv-none-elf-objcopy --remove-section  .riscv.attributes i2c_demo.elf
--- End code ---

This does not change the behaviour of gdb.

brucehoult:
Did you also update gdb when you uipdated gcc?

There is not enough information in RISC-V binary code to be able to reliably form a backtrace (there is no frame pointer, you don't necessarily know the stack frame size, and also the return address could be anywhere in it). Metadata is needed, and that could well change in format between gcc 8 and gcc 12.

GromBeestje:
Using riscv-none-elf-gdb which came with the xPack version of the gcc 12 compiler gives this behaviour.

But this brings another question. Could this relate to the ISA specification version? gcc 8 defaults to ISA 2.2, but for gcc 12, I need to specify ISA 2.2 manually, or it will default to a newer ISA. --- Still, in that case the resulting binary for both would be in ISA 2.2.

brucehoult:
As far as I know 2.2 is the newest version of the User-mode instructions, and even then only floating point had changes in 2.2, last changes to RV32I and RV64I were in 2.1.

There will NEVER be incompatible changes.

Navigation

[0] Message Index

[#] Next page