qemu-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Peter Maydell
Subject: Re: [Qemu-discuss] Segmentation fault on target tricore
Date: Tue, 17 Sep 2019 13:32:26 +0100

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()'

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]