On 28/4/19 10:34 pm, Chris Johns wrote:
>
>> On 28 Apr 2019, at 7:18 pm, dufa...@hda.com wrote:
>>
>> I think you might need to do two passes if that’s straight-forward. Then
>> you can count, lock, allocate, unlock, read.
>
> Or grouping the allocations together then the loading however doing
> On 28 Apr 2019, at 7:18 pm, dufa...@hda.com wrote:
>
> I think you might need to do two passes if that’s straight-forward. Then you
> can count, lock, allocate, unlock, read.
Or grouping the allocations together then the loading however doing this has
tripped a bug in dl09 on the PowerPC I
I think you might need to do two passes if that’s straight-forward. Then you
can count, lock, allocate, unlock, read.
> On Apr 27, 2019, at 22:09 , Chris Johns wrote:
>
> On 27/4/19 10:23 pm, dufa...@hda.com wrote:
>> This is because RTL locks out heap operations. For ELF
>> files
On 27/4/19 10:23 pm, dufa...@hda.com wrote:
> This is because RTL locks out heap operations. For ELF
> files /rtems_rtl_alloc_lock() /calls /rtem_rtl_alloc_heap() /and that
> calls /_RTEMS_Lock_allocator()/ which locks the heap. Then RTL calls /read()
> /and the NFS threads try to use the heap.
This is because RTL locks out heap operations. For ELF files
rtems_rtl_alloc_lock() calls rtem_rtl_alloc_heap() and that calls
_RTEMS_Lock_allocator() which locks the heap. Then RTL calls read() and the
NFS threads try to use the heap.
(gdb) up
#1 0x00135394 in rtems_rtl_alloc_lock ()
I found this trying to work on "#3740: Libld does not load incrementially
linked object file”. When I updated it hung loading the text segment (line
1005 in rtl-elf.c, hard hang, debug output below). I tracked it down to a
change that adds locking to the allocator.
- BSP:
