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