Hi Peter,
On 9/17/19 3:45 PM, Peter Maydell wrote:
On Tue, 17 Sep 2019 at 14:06, Konopik, Andreas wrote:
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 stac
On Tue, 17 Sep 2019 at 14:06, Konopik, Andreas wrote:
>
> >> 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
> >> DisasCo
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
Hi Andreas,
On 9/17/19 2:32 PM, Peter Maydell wrote:
On Tue, 17 Sep 2019 at 13:24, Konopik, Andreas 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 -> A
On Tue, 17 Sep 2019 at 13:24, Konopik, Andreas 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 buil
