Infinite loop on _Heap_Allocate

Thu Aug 24 13:33:11 UTC 2017

On 24 August 2017 at 14:22, LOPEZ CUEVA Patricia
<patricia.lopezcueva at thalesaleniaspace.com> wrote:
> Hi Jiri,
>
>
>
> Thanks for your quick reply. Indeed, I did not know that patches had to be
> applied to qemu, I thought it was only to the toolset.
>
>
>
> I have downloaded the three patches and tried to directly apply them to
> qemu-2.9.0 without success. The patches are intended for which version of
> qemu?

Hi Patricia,

If you also build qemu with the RSB it will select the correct version
and apply the patches for you. The build set is in
bare/config/devel/qemu.
I'm working to get those patches merged into upstream qemu but it
hasn't happened yet.

Goodluck,

Cillian.
>
>
>
> In the end, I managed to apply them by modifying them a bit (only very minor
> modifications), but it does not compile. Note that qemu-2.9.0 compiles
> without any problem without the patches.
>
>
>
> I will not include the whole compilation output because it is huge and it
> would not be useful. I will include only the first few lines of the
> compilation errors:
>
>
>
>   CC      sparc-softmmu/hw/sparc/grlib_ambapnp.o
>
> In file included from
> /usr/local/tools/qemu-2.9.0/include/exec/cpu-common.h:7:0,
>
>                  from /usr/local/tools/qemu-2.9.0/include/hw/hw.h:9,
>
>                  from /usr/local/tools/qemu-2.9.0/include/hw/qdev.h:4,
>
>                  from /usr/local/tools/qemu-2.9.0/include/hw/sysbus.h:6,
>
>                  from
> /usr/local/tools/qemu-2.9.0/hw/sparc/grlib_ambapnp.c:23:
>
> /usr/local/tools/qemu-2.9.0/include/exec/hwaddr.h:11:1: error: unknown type
> name ‘uint64_t’
>
> typedef uint64_t hwaddr;
>
> ^
>
> In file included from /usr/local/tools/qemu-2.9.0/include/qemu/bswap.h:4:0,
>
>                  from
> /usr/local/tools/qemu-2.9.0/include/exec/cpu-common.h:10,
>
>                  from /usr/local/tools/qemu-2.9.0/include/hw/hw.h:9,
>
>                  from /usr/local/tools/qemu-2.9.0/include/hw/qdev.h:4,
>
>                  from /usr/local/tools/qemu-2.9.0/include/hw/sysbus.h:6,
>
>                  from
> /usr/local/tools/qemu-2.9.0/hw/sparc/grlib_ambapnp.c:23:
>
> /usr/local/tools/qemu-2.9.0/include/fpu/softfloat.h:94:1: error: unknown
> type name ‘uint8_t’
>
> typedef uint8_t flag;
>
> ^
>
> /usr/local/tools/qemu-2.9.0/include/fpu/softfloat.h:137:1: error: unknown
> type name ‘uint16_t’
>
> typedef uint16_t float16;
>
> ^
>
> /usr/local/tools/qemu-2.9.0/include/fpu/softfloat.h:138:1: error: unknown
> type name ‘uint32_t’
>
> typedef uint32_t float32;
>
> ^
>
> /usr/local/tools/qemu-2.9.0/include/fpu/softfloat.h:139:1: error: unknown
> type name ‘uint64_t’
>
> typedef uint64_t float64;
>
> ^
>
> /usr/local/tools/qemu-2.9.0/include/fpu/softfloat.h:151:5: error: unknown
> type name ‘uint64_t’
>
>      uint64_t low;
>
>      ^
>
> /usr/local/tools/qemu-2.9.0/include/fpu/softfloat.h:152:5: error: unknown
> type name ‘uint16_t’
>
>      uint16_t high;
>
>      ^
>
>
>
> Currently I am trying to understand the reason for this behavior.
>
>
>
> Thanks.
>
>
>
> Patricia López Cueva
>
> R&D On-Board Software Engineer
>
> TAS-F Cannes
>
>
>
> De : Jiri Gaisler [mailto:jiri at gaisler.se]
> Envoyé : jeudi 24 août 2017 10:29
> À : LOPEZ CUEVA Patricia; users at rtems.org
> Objet : Re: Infinite loop on _Heap_Allocate
>
>
>
> Have you applied leon3 patches for qemu from https://gaisler.org/qemu ?
>
> These are needed to boot RTEMS binaries properly.
>
> Jiri.
>
>
>
> On 08/24/2017 10:22 AM, LOPEZ CUEVA Patricia wrote:
>
> Hello all !
>
>
>
> I’ve just installed rtems-4.8 on a Redhat 7 64 bits machine. I’ve installed
> the release version of rtems 4.8 and the following versions of the toolset:
>
> -          gcc 4.2.1 with newlib 1.15.0
>
> -          binutils 2.18
>
> -          gdb 6.8
>
>
>
> The compilation and installation of the toolset and rtems run without
> problem except for the documentation part which I disabled.
>
>
>
> Then I installed the rtems-4.8 examples and tried to run hello_world_c on
> qemu leon3 with the command “qemu-system-sparc -nographic -M leon3_generic
> -cpu LEON3 -kernel hello.exe -s –S”.
>
>
>
> Neither error nor warning was present in the compilation or the execution
> process (nor the hello world message) and when I stop the execution it is
> always on the _Heap_Allocate function of cpukit/score/src/heapallocate.c
> file. Here is the backtrace:
>
>
>
> (gdb) c
>
> Continuing.
>
>
>
> Program received signal SIGINT, Interrupt.
>
> _Heap_Allocate (the_heap=0x40013e6c, size=<value optimized out>) at
> ../../../../../../rtems-4.8.0/c/src/../../cpukit/score/src/heapallocate.c:57
>
> 57            the_block = the_block->next, ++search_count)
>
> (gdb) bt
>
> #0  _Heap_Allocate (the_heap=0x40013e6c, size=<value optimized out>) at
> ../../../../../../rtems-4.8.0/c/src/../../cpukit/score/src/heapallocate.c:57
>
> #1  0x4000b8c8 in _Workspace_Allocate_or_fatal_error (size=52) at
> ../../cpukit/../../../leon3/lib/include/rtems/score/wkspace.inl:37
>
> #2  0x4000b2e4 in _User_extensions_Handler_initialization
> (number_of_extensions=1, initial_extensions=0x40012cc0) at
> ../../../../../../rtems-4.8.0/c/src/../../cpukit/score/src/userext.c:37
>
> #3  0x40007860 in rtems_initialize_executive_early
> (configuration_table=0x40013930, cpu_table=0x40013908) at
> ../../../../../../rtems-4.8.0/c/src/../../cpukit/sapi/src/exinit.c:152
>
> #4  0x40001924 in boot_card (argc=0, argv=0x0, envp=0x0) at
> ../../../../../../../../rtems-4.8.0/c/src/lib/libbsp/sparc/leon3/../../shared/bootcard.c:117
>
> #5  0x400010dc in zerobss () at
> ../../../../../../../../rtems-4.8.0/c/src/lib/libbsp/sparc/leon3/../../sparc/shared/start.S:339
>
> #6  0x400010dc in zerobss () at
> ../../../../../../../../rtems-4.8.0/c/src/lib/libbsp/sparc/leon3/../../sparc/shared/start.S:339
>
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
>
> (gdb) p *the_heap
>
> $17 = {free_list = {prev_size = 0, size = 0, next = 0xfffc8040, prev =
> 0xfffc8040}, page_size = 8, min_block_size = 16, begin = 0xfffc8040, end =
> 0xfffd5e50, start = 0xfffc8040, final = 0xfffd5e48, stats = {instance = 0,
>
>     size = 56848, free_size = 56840, min_free_size = 56840, free_blocks = 1,
> max_free_blocks = 1, used_blocks = 0, max_search = 0, allocs = 0, searches =
> 0, frees = 0, resizes = 0}}
>
>
>
> It seems to be blocked on an infinite loop. I presume there has been a
> problem with the installation of rtems that I have not seen since this is a
> well proven version and it is the most basic example.
>
>
>
> Would you have an idea of what the problem might be?
>
>
>
> Thanks a lot in advance,
>
> Patricia Lopez Cueva
>
>
>
>
>
>
>
>
> _______________________________________________
>
> users mailing list
>
> users at rtems.org
>
> http://lists.rtems.org/mailman/listinfo/users
>
>
>
>
> _______________________________________________
> users mailing list
> users at rtems.org
> http://lists.rtems.org/mailman/listinfo/users