On Tue, 17 Sep 2019 at 13:24, Konopik, Andreas <andreas.kono...@fau.de> wrote: > > Hello, > > I am wondering why the "Hello world"-program available in TASKING > (v6.2r1) generates a segfault. > > I compiled the program for the 'TC1796' Processor (Infineon TriCore 1 > Family -> AUDO NextGeneration Family). > QEMU was built with gcc 9.1.0 and I added a memory region, that was > necessary [1]. > Running QEMU with following options: > `./qemu/build/tricore-softmmu/qemu-system-tricore -nographic -M > tricore_testboard -cpu tc1796 -kernel hello.elf` > led to a segfault in a short time
Hi -- I'm cc'ing the qemu-devel list and the TriCore maintainer; not everybody reads the -discuss mailing list. > Using gdb and valgrind I found out that: > - 'gen_mtcr()' and 'gen_mfcr()' access uninitialized values, i.e. CSFRs, > which leads to the Segfault > - The uninitialised values were created by stack allocation of > DisasContext in 'gen_intermediate_code()' This definitely sounds like a bug: do you have a stack backtrace from valgrind or gdb of the bad access and the segfault? > The segfault does not occur when configuring QEMU with '--enable-debug' > flag, so i suspect it might be a compiler error while building QEMU. > It did not come up before target/tricore implemented the > DisasContextBase API (commit d013d220c710054a6d755941460f88c186fef7b5). > > Does anybody else have this problem? > > > Regards, > > Andreas > > > > [1] Memory-layout addition (according to TASKING memory-layout): > > > diff --git a/hw/tricore/tricore_testboard.c > > b/hw/tricore/tricore_testboard.c > > index aef3289f8c..c287e0e7f5 100644 > > --- a/hw/tricore/tricore_testboard.c > > +++ b/hw/tricore/tricore_testboard.c > > @@ -59,6 +59,7 @@ static void tricore_testboard_init(MachineState > > *machine, int board_id) > > CPUTriCoreState *env; > > > > MemoryRegion *sysmem = get_system_memory(); > > + MemoryRegion *pflash = g_new(MemoryRegion, 1); > > MemoryRegion *ext_cram = g_new(MemoryRegion, 1); > > MemoryRegion *ext_dram = g_new(MemoryRegion, 1); > > MemoryRegion *int_cram = g_new(MemoryRegion, 1); > > @@ -68,6 +69,8 @@ static void tricore_testboard_init(MachineState > > *machine, int board_id) > > > > cpu = TRICORE_CPU(cpu_create(machine->cpu_type)); > > env = &cpu->env; > > + memory_region_init_ram(pflash, NULL, "pflash", > > + 2 * MiB, &error_fatal); > > memory_region_init_ram(ext_cram, NULL, "powerlink_ext_c.ram", > > 2 * MiB, &error_fatal); > > memory_region_init_ram(ext_dram, NULL, "powerlink_ext_d.ram", > > @@ -81,6 +84,7 @@ static void tricore_testboard_init(MachineState > > *machine, int board_id) > > memory_region_init_ram(pcp_text, NULL, "powerlink_pcp_text.ram", > > 32 * KiB, &error_fatal); > > > > + memory_region_add_subregion(sysmem, 0xa0000000, pflash); > > memory_region_add_subregion(sysmem, 0x80000000, ext_cram); > > memory_region_add_subregion(sysmem, 0xa1000000, ext_dram); > > memory_region_add_subregion(sysmem, 0xd4000000, int_cram); I don't know enough about TriCore or the board QEMU is emulating here to know whether this is the right thing; Bastian? thanks -- PMM
