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.hu...@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.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
