JTAG programming on the simulator results in corrupted memory

[kentindell]

When running hellow through the simulator, the output when using gdb/OpenOCD/JTAG is:

HellHellHellHellHellHellHellHellHellCPU requested halt. Exit code 123

When dumping the memory for the string from the simulated and via gdb shows that this is indeed the string value. OpenOCD shows some errors and warnings:

Error: [hazard3.cpu] Error when writing memory, abstractcs=0x2000301
Warn : [hazard3.cpu] Failed to write memory via program buffer.
Error: No working memory available. Specify -work-area-phys to target.
Warn : not enough working area available(requested 1100)

I'm assuming there''s some kind of memory allocation problem for gdb to push data into the target (so the first four bytes of the string are repeated across the memory). When asking gdb to verify the sections:

(gdb) compare-sections 
Section .text, range 0x0 -- 0x17e2: MIS-MATCHED!
Section .rodata, range 0x17e4 -- 0x1808: MIS-MATCHED!
Section .eh_frame, range 0x1808 -- 0x180c: matched.
Section .init_array, range 0x180c -- 0x1814: MIS-MATCHED!
Section .fini_array, range 0x1814 -- 0x1818: matched.
Section .data, range 0x1818 -- 0x1d50: MIS-MATCHED!
Section .sdata, range 0x1d50 -- 0x1d60: MIS-MATCHED!
warning: One or more sections of the target image does not match the loaded file

The code does actually run correctly (the simulator terminates with a value of 123, as expected). I guess this could be down to 'luck' though.

The versions of the software are:

Open On-Chip Debugger 0.12.0+dev-03959-gc85d4e185 (2024-09-12-14:42)

GNU gdb (GDB) 15.1

[Wren6991]

Thanks, I'm travelling without a PC at the moment but will look at this when I get back. So that I can reproduce could you please let me know:

• The Hazard3 version (tag or hash)
• The OpenOCD config file you are using
• The exact sequence of commands you run (bash + gdb)

[kentindell]

The hash is

a4412c0b00fd67788e42bc61599bf7a8c106d7b1

(the current repository HEAD).

The OpenOCD config file is unchanged.

The gdb commands are exactly as shown in Readme.md (they were copied and pasted).

My colleague discovered this first and so I followed the exact same build sequence, and replicated their result.

[roman65536]

I just tried to run in the simulator, get not same as above but very similar.

root@debian12:/home/hazard3/test/sim/tb_cxxrtl# riscv32-unknown-elf-gdb GNU gdb (GDB) 15.1 Copyright (C) 2024 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "--host=x86_64-pc-linux-gnu --target=riscv32-unknown-elf". Type "show configuration" for configuration details. For bug reporting instructions, please see: https://www.gnu.org/software/gdb/bugs/. Find the GDB manual and other documentation resources online at: http://www.gnu.org/software/gdb/documentation/.

For help, type "help". Type "apropos word" to search for commands related to "word". (gdb) target extended-remote localhost:3333 Remote debugging using localhost:3333 Info : accepting 'gdb' connection on tcp/3333 hazard3.cpu halted due to debug-request. warning: No executable has been specified and target does not support determining executable automatically. Try using the "file" command. 0x00000000 in ?? () (gdb) file ../hellow/tmp/hellow.elf A program is being debugged already. Are you sure you want to change the file? (y or n) y Reading symbols from ../hellow/tmp/hellow.elf... (No debugging symbols found in ../hellow/tmp/hellow.elf) (gdb) load Loading section .text, size 0x17e0 lma 0x0 Loading section .rodata, size 0x24 lma 0x17e0 Error: [hazard3.cpu] Error when writing memory, abstractcs=0x2000301 Error: [hazard3.cpu] Failed to write memory (addr=0x0) progbuf=failed, sysbus=disabled, abstract=disabled Load failed