Ping on ticket 4728 + patch
Sebastian Huber
sebastian.huber at embedded-brains.de
Fri Oct 28 12:07:14 UTC 2022
On 22/10/2022 17:36, Alan Cudmore wrote:
> On Thu, Oct 20, 2022 at 11:23 PM Alan Cudmore<alan.cudmore at gmail.com> wrote:
>> On Thu, Oct 20, 2022 at 2:13 AM Sebastian Huber
>> <sebastian.huber at 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.huber at embedded-brains.de> wrote:
>>>>> On 18/10/2022 21:02, Alan Cudmore wrote:
>>>>>> *From: *Sebastian Huber<mailto:sebastian.huber at embedded-brains.de>
>>>>>> *Sent: *Tuesday, October 18, 2022 11:15 AM
>>>>>> *To: *Alan Cudmore<mailto:alan.cudmore at gmail.com>;joel at rtems.org
>>>>>> <mailto:joel at rtems.org>
>>>>>> *Cc: *rtems-devel at rtems.org<mailto:devel at 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<joel at rtems.org> wrote:
>>>>>>
>>>>>> >>
>>>>>>
>>>>>> >>
>>>>>>
>>>>>> >> On Tue, Oct 18, 2022 at 8:44 AM Alan
>>>>>> Cudmore<alan.cudmore at 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.huber at 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/
More information about the devel
mailing list