dl06

Sebastian Huber sebastian.huber at embedded-brains.de
Tue Nov 19 06:36:48 UTC 2019


On 19/11/2019 01:59, Chris Johns wrote:
> On 18/11/19 7:12 pm, Sebastian Huber wrote:
>> On 18/11/2019 08:59, Chris Johns wrote:
>>>
>>>> On 18 Nov 2019, at 6:14 pm, Sebastian Huber
>>>> <Sebastian.Huber at embedded-brains.de> wrote:
>>>>
>>>> Hallo,
>>>>
>>>> on which platform passes the dl06 test? I tried arm/realview_pbx_a9_qemu and
>>>> got:
>>>
>>> It is a bug that has come in that I have not looked at.
>>
>> Is this a known issue or something which broke only recently? Do you know a
>> version/platform on which it worked?
> 
> The test broke a while ago when I made a change to ELF loading issues. I forget
> what the change was. I need to take a look and fix it but doing so means I need
> to revisit the RAP format and it's support and so it will take a bit of time to
> work through. I have had other more pressing things to working on.

This is not an issue, I just have to know if something broke due to the 
build system changes.

> 
>>>> *** BEGIN OF TEST libdl (RTL) 6 ***
>>>> *** TEST VERSION: 5.0.0.9438165d2cfb9a6a67f01f5ec7ba9156abb66d7d-modified
>>>> *** TEST STATE: EXPECTED-PASS
>>>> *** TEST BUILD: RTEMS_NETWORKING RTEMS_POSIX_API RTEMS_SMP
>>>> *** TEST TOOLS: 7.4.1 20190514 (RTEMS 5, RSB
>>>> a50f0c044ad732db728cc942d5fde82a1faf1d12, Newlib d14714c69)
>>>>
>>>> load: /dl06.rap
>>>> handle: 0x210ce0 loaded
>>>> Loaded module: argc:4
>>>> [/home/EB/sebastian_h/git-rtems-5/c/src/../../testsuites/libtests/dl06/dl06-o1.c]
>>>>
>>>> libm: lcong48
>>>> libm: atan2
>>>>
>>>> *** FATAL ***
>>>> fatal source: 9 (RTEMS_FATAL_SOURCE_EXCEPTION)
>>>>
>>>> R0   = 0x00000000 R8  = 0x00000000
>>>> R1   = 0x0000000a R9  = 0x00000000
>>>> R2   = 0x00213149 R10 = 0x00000000
>>>> R3   = 0x00000000 R11 = 0x00000000
>>>> R4   = 0x00206cac R12 = 0x00000000
>>>> R5   = 0x00000000 SP  = 0x00206c80
>>>> R6   = 0x00000000 LR  = 0x00211e51
>>>> R7   = 0x00206c80 PC  = 0x00211e94
>>>> CPSR = 0x00070173 VEC = 0x00000001
>>>> FPEXC = 0x40000000
>>>> FPSCR = 0x00000000
>>>> D00 = 0x401c666666666666
>>>> D01 = 0x4040800000000000
>>>> D02 = 0x3fddac670561bb4f
>>>> D03 = 0x3fe921fb54442d18
>>>> D04 = 0x3fef730bd281f69b
>>>> D05 = 0x3ff921fb54442d18
>>>> D06 = 0x3c7a2b7f222f65e2
>>>> D07 = 0x3c81a62633145c07
>>>> D08 = 0x0000000000000000
>>>> D09 = 0x0000000000000000
>>>> D10 = 0x0000000000000000
>>>> D11 = 0x0000000000000000
>>>> D12 = 0x0000000000000000
>>>> D13 = 0x0000000000000000
>>>> D14 = 0x0000000000000000
>>>> D15 = 0x0000000000000000
>>>> D16 = 0x0000000000000000
>>>> D17 = 0x0000000000000002
>>>> D18 = 0x0000000000000000
>>>> D19 = 0x0000000000000000
>>>> D20 = 0x0000000000000000
>>>> D21 = 0x0000000000000000
>>>> D22 = 0x0000000000000000
>>>> D23 = 0x0000000000000000
>>>> D24 = 0x0000000000000000
>>>> D25 = 0x0000000000000000
>>>> D26 = 0x0000000000000000
>>>> D27 = 0x0000000000000000
>>>> D28 = 0x0000000000000000
>>>> D29 = 0x0000000000000000
>>>> D30 = 0x0000000000000000
>>>> D31 = 0x0000000000000000
>>>> RTEMS version: 5.0.0.9438165d2cfb9a6a67f01f5ec7ba9156abb66d7d-modified
>>>> RTEMS tools: 7.4.1 20190514 (RTEMS 5, RSB
>>>> a50f0c044ad732db728cc942d5fde82a1faf1d12, Newlib d14714c69)
>>>> executing thread ID: 0x08a010001
>>>> executing thread name: UI1
>>>>
>>>> I tried arm/xilinx_zynq_a9_qemu and got:
>>>>
>>>> *** BEGIN OF TEST libdl (RTL) 6 ***
>>>> *** TEST VERSION: 5.0.0.799c4f551806fb1124ea5d9f6633ec5deb91ad8e
>>>> *** TEST STATE: EXPECTED-PASS
>>>> *** TEST BUILD: RTEMS_DEBUG RTEMS_POSIX_API
>>>> *** TEST TOOLS: 7.4.1 20190514 (RTEMS 5, RSB
>>>> a50f0c044ad732db728cc942d5fde82a1faf1d12, Newlib d14714c69)
>>>>
>>>> load: /dl06.rap
>>>> dlopen failed: .text: THM_CALL/JUMP24: overflow: no tramp memory
>>>>
>>>> *** FATAL ***
>>>> fatal source: 5 (RTEMS_FATAL_SOURCE_EXIT)
>>>> fatal code: 0 (0x00000000)
>>>> RTEMS version: 5.0.0.799c4f551806fb1124ea5d9f6633ec5deb91ad8e
>>>> RTEMS tools: 7.4.1 20190514 (RTEMS 5, RSB
>>>> a50f0c044ad732db728cc942d5fde82a1faf1d12, Newlib d14714c69)
>>>> executing thread ID: 0x08a010001
>>>> executing thread name: UI1
>>>>
>>>> I would like to remove the PAX archives to simplify the build and reduce the
>>>> host dependencies.
>>>
>>> Is this because of handled the dependencies in waf?
>>
>> It is not a waf issue. I just want to get rid of another host dependency. pax is
>> not a standard Linux tool.
> 
> What do you mean when you say Linux is not standard, I get so confused with all
> the distros?
> 
> I thought it was a standard tool and part of POSIX or something like that,
> checking, hmm yeah it is. This is why we changed, supporting standards and all
> that sort of thing.

Yes, it is a POSIX tool, but it is not installed by default on some 
distributions. We had several mailing list posts related to this.

> 
> I am fine with tar being used if configure magic is used to select it. This may
> expose RTEMS tar support bugs, I cannot remember now.

Is tar supported by RTEMS? The last time I tried to use didn't work as 
far as I remember. Maybe it is related to our two independent untar 
solutions (<rtems/untar.h> and rtems_tarfs_load()).

> 
> I do not use Linux and so I do not see these changes.
> 
>>> Converting to C is a broken path IMO. it does not scale.
>>
>> I would convert the individual object files with bin2c and load them with
>> IMFS_make_linfile().
> 
> I see this as a broke way to handle building root file systems and to further
> embed in our build system and processes. Our users inspect what we do and take
> that as a lead and copy it. As I stated and Jonathan confirmed it does not
> scale. My preferred method is to use objcopy and to convert the bin tar file to
> an object file.

Using the right options for objcopy is not easy. The .incbin approach 
seems to work on a lot of platforms:

https://github.com/graphitemaster/incbin

Anyway, I just want to convert the stuff to a new build system. I will 
now try to stay as close to the existing solution as possible.

>>> I am not sure removing pax solves the need for 2 link passes.
>>>
>>>> It is not clear to me what the purpose of the dl06_pre_file file is.
>>>
>>> It tests the RAP format.
>>
>> How is the file used?
> 
> It is a format dlopen() understands and can load. 

I mean this file:

dl06-pre.tar: Makefile
	$(AM_V_at)echo "Something in a file" > dl06_pre_file
	$(AM_V_GEN)$(PAX) -w -f $@ dl06_pre_file

> It provides a single
> encapsulation of loading an application by having some of the work done on a
> host rather than the target. It is a hybrid approach to loading on a single
> address space resource limited embedded system. It can hold a number of object
> files and it supports compression.
> 
> When I made the latest set of libdl changes to add archive searching for the ELF
> format I was wondering if the RAP format was being used because I received
> little if any feedback or bugs on it. To my surprise I broke the RAP format with
> the archive searching changes and received a patch to fix it. It is being used
> in flight in a MIPS based satellite.
> 
> Chris
> 

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.


More information about the devel mailing list