On 22/10/2022 17:36, Alan Cudmore wrote:
On Thu, Oct 20, 2022 at 11:23 PM Alan Cudmore<alan.cudm...@gmail.com> wrote:
On Thu, Oct 20, 2022 at 2:13 AM Sebastian Huber
<sebastian.hu...@embedded-brains.de> wrote:
On 20/10/2022 03:48, Alan Cudmore wrote:
On Wed, Oct 19, 2022 at 12:24 AM Sebastian Huber
<sebastian.hu...@embedded-brains.de> wrote:
On 18/10/2022 21:02, Alan Cudmore wrote:
*From: *Sebastian Huber<mailto:sebastian.hu...@embedded-brains.de>
*Sent: *Tuesday, October 18, 2022 11:15 AM
*To: *Alan Cudmore<mailto:alan.cudm...@gmail.com>;j...@rtems.org
<mailto:j...@rtems.org>
*Cc: *rtems-de...@rtems.org<mailto:devel@rtems.org>
*Subject: *Re: Ping on ticket 4728 + patch
On 18/10/2022 16:36, Alan Cudmore wrote:
> On Tue, Oct 18, 2022 at 9:55 AM Joel Sherrill<j...@rtems.org> wrote:
>>
>>
>> On Tue, Oct 18, 2022 at 8:44 AM Alan
Cudmore<alan.cudm...@gmail.com> wrote:
>>> The log does have the error, and I get it when building by hand too:
>>> start.o: in function `.L0 ':
>>>
/home/alan/rtems/test-build/rtems-tmp/build/riscv/rv32imafdc/../../../bsps/riscv/shared/start/start.S:86:(.bsp_start_text+0x5c):
>>> relocation truncated to fit: R_RISCV_GPREL_I against symbol
>>> `bsp_section_bss_size' defined in*ABS* section in
>>>
/home/alan/rtems/test-build/rtems-tmp/build/riscv/rv32imafdc/testsuites/samples/minimum.exe
>>> collect2: error: ld returned 1 exit status
>>
>>
>> Hmmm.. that's weird. You should never get a truncation error linking
minimum.exe.
>> It should always fit within the BSP's memory and not have any issues
with branches
>> or calls needing fixup.
>>
>> Unless the wrong type of branch/jump/call instruction is used at
start.S:86, I have
>> no idea.If it's a form that assumes a short distance to the
destination but is going
>> to a symbol outside start.S and thus could be further.
> Also, 6 of the samples such as hello.exe link without error.
> The rv32imafdc BSP variant does not have CPU_CFLAGS.
> rv32imafd links fine and has specific CPU_CFLAGS, rv32imafdc does not
> have the flags.
> (I'll research the gcc defaults and architecture differences next..)
>
> I get a similar error on the frdme310arty BSP but only on a specific
> POSIX testsuite executable:
>
> start.o: in function `.L0 ':
>
>
/home/alan/rtems/test-build/rtems-tmp/build/riscv/frdme310arty/../../../bsps/riscv/shared/start/start.S:86:(.bsp_start_text+0x28):
> relocation truncated to fit: R_RISCV_GPREL_I against symbol
> `bsp_section_bss_size' defined in*ABS* section in
>
/home/alan/rtems/test-build/rtems-tmp/build/riscv/frdme310arty/testsuites/validation/ts-validation-io-kernel.exe
>
> collect2: error: ld returned 1 exit status
My off hand guess is that this is a tool chain issue on certain host
systems. For example, I never got this error on our OpenSUSE machines.
I can set up a OpenSUSE virtual machine and try it. I noticed the RSB
documentation does not have a set of packages for OpenSUSE – I could
send a docs patch after a successful build. What release do you use? Do
you have a list of packages to install?
We use openSUSE Leap 15.3 and 15.4. To get the packages maybe try this:
zypper in -t pattern devel_C_C++ devel_python3
I was able to set up an openSUSE Leap 15.4 (64 bit) VM and the above
packages worked for the RSB build.
Unfortunately, I still get the same link error for minimum.exe. Do you
think this is a linker error? Is it worth trying a Clang build?
I am not really sure what it its, since I never got this error on one of
our machines.
What happens if you compile the attached files with:
riscv-rtems6-gcc start.S abs.S -Wl,-gc-sections
This produces a.out without error. I can post the symbols or objdump
header info if that would help.
For the minimum.exe failure, I can add:
volatile int x = 0;
to the Init function and the error goes away.
I can also get the error to go away if I add RTEMS_POSIX_API=True to config.ini
I suspect that what I am doing is adding just enough code or data to
move the bss symbol close enough to the global pointer. I can try to
compare the map for minimum.exe for both the original and modified
version that does link. The original version will produce an
executable if I use -Wl,--noinhibit-exec
I have been looking for similar errors, and there are some interesting
bug reports and discussions for GNU ld on RISC-V such as this:
https://mail.gnu.org/archive/html/bug-binutils/2021-03/msg00164.html
But that discussion is over a year old.
I can eliminate both cases of the error that I see by adding
-Wl,--no-relax to the linker, which inhibits the linker based code
size optimization that is possibly causing this. The downside is that
the code size increases. minimum.exe code grows from 290431 to 292369
bytes for the rv32imafdc bsp variant.
Based on the binutils discussion, maybe there have been adjustments to
the link scripts needed to account for recent fixes in ld?
Is there a "default" set of ld scripts for each architecture? If so, I
can compare those to the RTEMS RISC-V ldscripts.
I had this issue now for the first time on one of my machines. I checked
in the following workaround:
https://git.rtems.org/rtems/commit/?id=89ba2a9838558841c4f38283e84b99173790d61c
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
