Link RAP file error on zynq BSP

[jameszxj]

>


>On 12/10/18 10:05 am, Joel Sherrill wrote:
>>>
>>>
>>> On Thu, Oct 11, 2018 at 11:45 PM jameszxj <jameszxj at gmail.com
>>> <mailto:jameszxj at gmail.com>> wrote:
>>>
>>>     HI,
>>>         I run RTEMS on my xilinx z7k board and dynamic load application(RAP
>>>     format) from shell.
>>>     In recent update, i encount a link error when link the RAP file.
>>>     Here is the command and output message:
>>>                     rtems-ld -n -e PT_Init --base rtems-nsa.elf
>>>     wsp/build/nssys.elf -o wsp/build/nssys.out
>>>                     error: rap::object: Section index '65522' not found:
>>>     wsp/build/nssys.elf
>>>
>>>         At last I found the bsp_spec file has been modified,  "*link:%{!qrtems:
>>>     %(old_link)} %{qrtems: -dc -dp -N}" was removed
>>>     from the bsp_spec file.  Add this line to the file, ld is OK.
>>>        Why removed these lines?
>>>
>>>
>>> The long-term goal is to remove the bsp_specs. I made a sweep making them more
>>> consistent and have a set of patches against gcc master which eliminates them on
>>> many architectures. Working so the details are implied by GCC.
>>>
>>> So let's look at the options and see which one has an impact which mattered that
>>> I didn't catch. This is the description of these options from ld's man page:
>>>
>>>       -N
>>>        --omagic
>>>            Set the text and data sections to be readable and writable.  Also,
>>>            do not page-align the data segment, and disable linking against
>>>            shared libraries.  If the output format supports Unix style magic
>>>            numbers, mark the output as "OMAGIC". Note: Although a writable
>>>            text section is allowed for PE-COFF targets, it does not conform to
>>>            the format specification published by Microsoft.
>>>
>>>       -d
>>>       -dc
>>>        -dp These three options are equivalent; multiple forms are supported
>>>            for compatibility with other linkers.  They assign space to common
>>>            symbols even if a relocatable output file is specified (with -r).
>>>            The script command "FORCE_COMMON_ALLOCATION" has the same effect.
>>>
>>> I'm going to guess that it is -dc/-dp but have no idea how this would impact RAP
>>> except to confuse the code.
>>>
>>> Can you try adding adding the options one at a time until you make it work? Then
>>> Chris can figure out why it breaks RAP.>>


>I have tried this,just add -dc/-dp do not make it work.>


>>I suspect there is a section that is present which is needed that is not being
>>handled in the RAP toolkit code. That RAP format merges some sections in rtems-ld.>>


>Probably like this, and I just test it use just one simple source file, uninitialized variable


                                                                        ^^^^^^^^^^^^^^^^^^^^^^^^uninitialized global variable
>cause this error. If I initialize the variable, link is fine.>
>


>>James, if you can make a test file that generates the error then create a ticket
>>and attach the code I can take a look.>>


>>>
>>>        Does the newest RTEMS support the loading of incrementally linked ELF
>>>     files? RAP format runs OK, but the link needs BSP image, this
>>>     make BSP's development and APP's development not so independent. a little
>>>     pity, :)
>>>
>>> This is a Chris question.
>>>
>>James, if you do not provide a base image, ie no --base option, what happens?>>


>I am trying to figure out the problem, it maybe has sth. to do with the --nostdlib option,
>I need to do more tests. I shall describe the problem more clear later on.>


I compile APP with --nostdlib option, link process need to resolve the symbols through base iamge, so BSP image is needed.
And if I remove --nostdlib and add -lc -lm ... , I got a error message:


d:/msys64/opt/rtems/5.1/bin/../lib/gcc/arm-rtems5/7.3.0/../../../../arm-rtems5/bin/ld.exe: wsp/build/nssys.elf section `.unexpected_sections' will not fit in region `UNEXPECTED_SECTIONS'
collect2.exe: error: ld returned 1 exit status




>>Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20181015/f65abf83/attachment-0002.html>