Re: Link RAP file error on zynq BSP

2018-11-11 Thread Chris Johns
On 12/10/2018 15:45, jameszxj 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

I have tracked the section number 65522 to being an uninitialised variable in a
module being loaded. For ELF this means:

 int sym1;

creates a symbol record in ELF in libdl of:

rtl: sym:elf:24 name:70:sym1 bind:1  type:1  sect:65522 size:4

The readelf version is:

   24: 0004 4 OBJECT  GLOBAL DEFAULT  COM sym1

I have finally managed to find what out where these sections are defined ...

https://git.rtems.org/rtems/tree/cpukit/include/sys/exec_elf.h#n538

Peng Fan came across this issue in GSoC 2013 (2012?) on the sparc but we could
not find anything in the standards or supporting code to tell what it was and
why it existed. We seem to have just missed this detail.

The `rtems-ld` linker has support for this section hard coded into it but it is
restricted to the sparc architecture. Now I have something in the standard
headers to work with I should be able to handle this case cleanly and on all
supported archs.

James, there is no need for a test case.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Link RAP file error on zynq BSP

2018-11-10 Thread Chris Johns
On 15/10/18 9:39 pm, jameszxj wrote:
>>It should be fixed with this commit:
> 
>> https://git.rtems.org/rtems/commit/?id=186a0b1dc017b1e2e44620f8d6274dc1c6ba09d1
> 
> thanks, compile is ok. but rtems-ld still has a error
> 
> outputter:application: wsp/build/nssys.out
> image::close: removing wsp/build/nssys.out
> error: rap::object: Section index '65522' not found: wsp/build/nssys.elf
> make: *** [Makefile:103: nssys.elf] Error 10
> 
> should  rtems-ld be patch too?
> 

James, you do have a test case I can use to look into this?

Thanks
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Link RAP file error on zynq BSP

2018-10-15 Thread jameszxj
>It should be fixed with this commit:

> https://git.rtems.org/rtems/commit/?id=186a0b1dc017b1e2e44620f8d6274dc1c6ba09d1

thanks, compile is ok. but rtems-ld still has a error


outputter:application: wsp/build/nssys.out
image::close: removing wsp/build/nssys.out
error: rap::object: Section index '65522' not found: wsp/build/nssys.elf
make: *** [Makefile:103: nssys.elf] Error 10


should  rtems-ld be patch too?

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

Re: Link RAP file error on zynq BSP

2018-10-15 Thread Sebastian Huber

On 15/10/2018 10:16, jameszxj wrote:


*From: * "Sebastian Huber";
*Date: * Mon, Oct 15, 2018 02:43 PM
*To: * "devel";
*Cc: * "jameszxj";
*Subject: * Re: Link RAP file error on zynq BSP

On 15/10/2018 08:16, jameszxj wrote:
>> 
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

>Please have a look at the linker map file to figure out what these
>sections are.


.unexpected_sections
                0x0001        0x0
 *(*)
 .tm_clone_table
                0x0001        0x0 
d:/msys64/opt/rtems/5.1/bin/../lib/gcc/arm-rtems5/7.3.0/thumb/armv7-a/neon/hard/crtbegin.o

 .tm_clone_table
                0x0001        0x0 
d:/msys64/opt/rtems/5.1/bin/../lib/gcc/arm-rtems5/7.3.0/thumb/armv7-a/neon/hard/crtend.o

                0x0001 __TMC_END__
END GROUP
LOAD 
d:/msys64/opt/rtems/5.1/bin/../lib/gcc/arm-rtems5/7.3.0/thumb/armv7-a/neon/hard/crtend.o
LOAD 
d:/msys64/opt/rtems/5.1/bin/../lib/gcc/arm-rtems5/7.3.0/thumb/armv7-a/neon/hard/crtn.o

OUTPUT(wsp/build/nssys.elf elf32-littlearm)



It should be fixed with this commit:

https://git.rtems.org/rtems/commit/?id=186a0b1dc017b1e2e44620f8d6274dc1c6ba09d1

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

Re: Link RAP file error on zynq BSP

2018-10-15 Thread Sebastian Huber

On 15/10/2018 08:16, jameszxj wrote:
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


Please have a look at the linker map file to figure out what these 
sections are.


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


Re: Link RAP file error on zynq BSP

2018-10-15 Thread jameszxj
>


>On 12/10/18 10:05 am, Joel Sherrill wrote:
>>>
>>>
>>> On Thu, Oct 11, 2018 at 11:45 PM jameszxj >> > 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___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Link RAP file error on zynq BSP

2018-10-14 Thread jameszxj
On 12/10/18 10:05 am, Joel Sherrill wrote:
>> 
>> 
>> On Thu, Oct 11, 2018 at 11:45 PM jameszxj > > 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
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.


>Chris___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Link RAP file error on zynq BSP

2018-10-12 Thread Chris Johns


On 12/10/18 10:05 am, Joel Sherrill wrote:
> 
> 
> On Thu, Oct 11, 2018 at 11:45 PM jameszxj  > 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 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.

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?

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Link RAP file error on zynq BSP

2018-10-12 Thread Joel Sherrill
On Thu, Oct 11, 2018 at 11:45 PM jameszxj  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.


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

> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel