Ping on ticket 4728 + patch
Alan Cudmore
alan.cudmore at gmail.com
Sat Oct 22 15:36:15 UTC 2022
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.
> >
> > --
> > 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