dl06

[Chris Johns]

On 19/11/19 5:36 pm, Sebastian Huber wrote:
> 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.

Great.

>>>>> 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.

Yes, it is painful how this tool is treated in some distros.

>> 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 am using it in some applications but I cannot remember how so I suppose the
answer is yes. Joel reminded me yesterday it was ustar or something like that
which has caused us problems.

>> 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

I had not seen this before now, it looks interesting.

> 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.

OK.

>>>> 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

<belch> ....

You need a successful first pass link to create the base image symbol table that
is linked into the executable in the second pass. The libdl tests embed the
symbols [1] which means the second link pass can move addresses and the embedded
symbol table's symbol references will adjust. All you need to get right is the
symbol list in the first pass match and symbols in the second pass. We need a
tar file, any tar file with the correct name to successfully complete the first
link pass.

Why use a dummy tar file and not the actual one? The real tar file contains the
RAP file which is created using rtems-ld and it references the first link pass
base image for the list of symbols present. The dummy tar file breaks the
dependency loop.

Chris

[1] https://docs.rtems.org/branches/master/user/exe/loader.html#embedded-symbols