Infinite loop on _Heap_Allocate
LOPEZ CUEVA Patricia
patricia.lopezcueva at thalesaleniaspace.com
Thu Aug 24 13:22:43 UTC 2017
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?
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<mailto:users at rtems.org>
http://lists.rtems.org/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20170824/4ed35421/attachment-0001.html>
More information about the users
mailing list