Re: [Qemu-discuss] Segmentation fault on target tricore

[Bastian Koppelmann]

Hi Andreas,

On 9/17/19 2:32 PM, Peter Maydell wrote:
> On Tue, 17 Sep 2019 at 13:24, Konopik, Andreas <address@hidden> 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()'


Sounds like a thing we already fixed (see 
https://lists.gnu.org/archive/html/qemu-devel/2019-06/msg05496.html). 
However, I see that you used a version already containing the fix.


> This definitely sounds like a bug: do you have a stack
> backtrace from valgrind or gdb of the bad access and the
> segfault?


Yes, or a small reproducer program.


> > > 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?


As the name suggest this is just a Testboard (and thus is not linked to 
any real board) that initializes the minimal amount of memory that is 
needed to run a binary. If you're interested you can implement a real 
board. I'm happy to take such a patch :)


Cheers,

Bastian