| Message ID | 1990856.EDz1xKh0BM@raillard-dv6 |
|---|---|
| State | Not Applicable |
| Headers | show |
Douglas, On Thu, 27 Aug 2015 21:11:18 +0200, Douglas RAILLARD wrote: > Cortex M3 no-MMU toolchain includes the elf2flt tool to convert ELF to bFLT. > However, it does not seem to be able to do its job when given the ELF output > of gcc 4.9.3 and uClibc 0.9.33. > The problem is: .ARM.exidx sections and .ARM.extab input sections are > not kept by the elf2flt linker script and libgcc apparently needs that > information (actually, a symbol for the beginning and the end of the > .ARM.exidx sections): > output/build/host-gcc-final-4.9.3/build/arm-buildroot-uclinux-uclibcgnueabi/libgcc/../../../libgcc/unwind-arm-common.inc:275: undefined reference to « __exidx_start » > This error shows up during the final link of a binary, not when > compiling the toolchain itself. > > A patch has been sent here 3 years ago but for some reasons, has not been > checked in buildroot: > http://article.gmane.org/gmane.comp.lib.uclibc.buildroot/40885/match=elf2flt Because it was not a proper patch: the e-mail mixed some kernel changes, with elf2flt changes and Buildroot changes. Definitely not something we could have applied. > Now elf2flt sources had been moved out of the buildroot tree, but the currently > used upstream has no obvious mean of contact so here is a serie of small patches that > allow the elf2flt toolchain to compile cleanly C code (C++ not tested). Can you submit this as proper patches against Buildroot, i.e a patch adding patches in package/elf2flt/ ? Also, can you ask on the nommu.org mailing list (http://lists.nommu.org/listinfo/nommu) is they have a new official upstream location for elf2flt ? > Also, support for two relocations types (R_ARM_NONE, R_ARM_PREL31) must be > added to elf2flt in order to process the content of .ARM.exidx section. > Note that I have not already tested the resulting binaries, only that > buildroot builds the root image without error, but Sourcery 2010q1 > uClinux prebuilt toolchain default linker script does a similar thing. > Unfortunately, I have not been able to find the sources of the elf2flt > binary included in that prebuilt toolchain yet. > > Here is the URL of that prebuilt toolchain: > https://sourcery.mentor.com/public/gnu_toolchain/arm-none-linux-gnueabi/arm-2010q1-202-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2 Are you sure? This is a Linux toolchain, not a uClinux toolchain. If you want the sources of: http://sourcery.mentor.com/public/gnu_toolchain/arm-uclinuxeabi/arm-2011.03-46-arm-uclinuxeabi-i686-pc-linux-gnu.tar.bz2 they are available at: http://sourcery.mentor.com/public/gnu_toolchain/arm-uclinuxeabi/arm-2011.03-46-arm-uclinuxeabi.src.tar.bz2 And this one does have the sources of elf2flt: arm-2011.03-46-arm-uclinuxeabi/elf2flt-2011.03-46.tar.bz2 Best regards, Thomas
Thomas On Friday 28 August 2015 11:53:14, Thomas Petazzoni wrote: > > Now elf2flt sources had been moved out of the buildroot tree, but the > > currently used upstream has no obvious mean of contact so here is a serie > > of small patches that allow the elf2flt toolchain to compile cleanly C > > code (C++ not tested). > Can you submit this as proper patches against Buildroot, i.e a patch > adding patches in package/elf2flt/ ? Sure, I'll patch my patch to create a patch adding patches right away. > Also, can you ask on the nommu.org mailing list > (http://lists.nommu.org/listinfo/nommu) is they have a new official > upstream location for elf2flt ? Sure > > Here is the URL of that prebuilt toolchain: > > https://sourcery.mentor.com/public/gnu_toolchain/arm-none-linux-gnueabi/ar > > m-2010q1-202-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2 > Are you sure? This is a Linux toolchain, not a uClinux toolchain. Well, it runs on linux host and output working bFLT binaries (runtime tested) for a uClinux target. Not a lot of people seems to be working with uClinux, but I found that this toolchain was the one used by most of people working with the stm32f429-discovery board, probably because Emcraft Systems has released a BSP for that board and they point to (nearly) that toolchain. (http://www.emcraft.com/stm32f429discovery#release-materials). > If you want the sources of: > > > http://sourcery.mentor.com/public/gnu_toolchain/arm-uclinuxeabi/arm-2011.03 > -46-arm-uclinuxeabi-i686-pc-linux-gnu.tar.bz2 > > they are available at: > > > http://sourcery.mentor.com/public/gnu_toolchain/arm-uclinuxeabi/arm-2011.03 > -46-arm-uclinuxeabi.src.tar.bz2 > > And this one does have the sources of elf2flt: > > arm-2011.03-46-arm-uclinuxeabi/elf2flt-2011.03-46.tar.bz2 I'll study these sources, as they should handle correctly the .ARM.exidx and .ARM.extab sections, thanks for the pointer. Caveat: From https://github.com/jserv/stm32f429-linux-builder: SourceryG++ arm-2011.03 is known to NOT work (but elf2flt is probably still useable). Best regards, Douglas
Dear Douglas RAILLARD, On Fri, 28 Aug 2015 15:15:34 +0200, Douglas RAILLARD wrote: > > Also, can you ask on the nommu.org mailing list > > (http://lists.nommu.org/listinfo/nommu) is they have a new official > > upstream location for elf2flt ? > > Sure In the mean time, Waldemar pointed to his own Git tree of elf2flt. Still, it would be great to have some kind of "official" upstream place for elf2flt development. > I'll study these sources, as they should handle correctly the .ARM.exidx and > .ARM.extab sections, thanks for the pointer. > Caveat: From https://github.com/jserv/stm32f429-linux-builder: > SourceryG++ arm-2011.03 is known to NOT work (but elf2flt is probably still > useable). You can find all other versions, including sources, at http://sourcery.mentor.com/public/gnu_toolchain/. Best regards, Thomas
Hi Thomas, Thomas Petazzoni wrote, > Dear Douglas RAILLARD, > > On Fri, 28 Aug 2015 15:15:34 +0200, Douglas RAILLARD wrote: > > > > Also, can you ask on the nommu.org mailing list > > > (http://lists.nommu.org/listinfo/nommu) is they have a new official > > > upstream location for elf2flt ? > > > > Sure > > In the mean time, Waldemar pointed to his own Git tree of elf2flt. > Still, it would be great to have some kind of "official" upstream place > for elf2flt development. I think elf2flt from my GIT is the best you get ;) The official CVS repository from uclinux project is down since years. The uclinux project maintainer told me following: http://mailman.uclinux.org/pipermail/uclinux-dev/2014-August/052560.html No ETA. As uClibc-ng is the only C library I know of, which is using BFLT, it belongs to uClibc-ng and I will maintain it. nommu.org focus is to use musl C library for at the moment sh2 target, which will _not_ use BFLT. It will use ELF with static PIE. See here about some notes from Rich Felker: http://www.openwall.com/lists/musl/2015/08/26/1 best regards Waldemar
Hi Waldemar, On Friday 28 August 2015 17:02:03, Waldemar Brodkorb wrote: > As uClibc-ng is the only C library I know of, which is using BFLT, > it belongs to uClibc-ng and I will maintain it. So maybe the best solution is just to fix the build of elf2flt in buildroot and switch to Waldemar repo as upstream for buildroot's elf2flt ? > nommu.org focus is to use musl C library for at the moment sh2 > target, which will _not_ use BFLT. It will use ELF with static PIE. > See here about some notes from Rich Felker: > http://www.openwall.com/lists/musl/2015/08/26/1 I've already asked on nommu.org mailing list, we'll see what comes out. Best regards, Douglas
Dear Douglas RAILLARD, On Fri, 28 Aug 2015 17:27:10 +0200, Douglas RAILLARD wrote: > On Friday 28 August 2015 17:02:03, Waldemar Brodkorb wrote: > > As uClibc-ng is the only C library I know of, which is using BFLT, > > it belongs to uClibc-ng and I will maintain it. > So maybe the best solution is just to fix the build of elf2flt in buildroot > and switch to Waldemar repo as upstream for buildroot's elf2flt ? Yes, it could be one solution. > > nommu.org focus is to use musl C library for at the moment sh2 > > target, which will _not_ use BFLT. It will use ELF with static PIE. > > See here about some notes from Rich Felker: > > http://www.openwall.com/lists/musl/2015/08/26/1 > > I've already asked on nommu.org mailing list, we'll see what comes out. Good, thanks. Thomas
--- host-elf2flt-21c6a41885ad544763ccd19883c1353f3b0b7a47/elf2flt.ld.in 2012-10-04 04:32:38.000000000 +0200 +++ host-elf2flt-21c6a41885ad544763ccd19883c1353f3b0b7a47/elf2flt.ld.in 2015-08-27 17:21:14.115151557 +0200 @@ -142,8 +142,12 @@ .gcc_except_table : { KEEP(*(.gcc_except_table)) KEEP(*(.gcc_except_table.*)) - } >flatmem - + } >flatmem + .ARM.extab : { *(.ARM.extab* .gnu.linkonce.armextab.*) } > flatmem + PROVIDE_HIDDEN (@SYMBOL_PREFIX@__exidx_start = .); + .ARM.exidx : { *(.ARM.exidx* .gnu.linkonce.armexidx.*) } > flatmem + PROVIDE_HIDDEN (@SYMBOL_PREFIX@__exidx_end = .); + . = ALIGN(0x10) ; @SYMBOL_PREFIX@_edata = . ; --- host-elf2flt-21c6a41885ad544763ccd19883c1353f3b0b7a47//elf2flt.c 2012-10-04 04:32:38.000000000 +0200 +++ host-elf2flt-21c6a41885ad544763ccd19883c1353f3b0b7a47/elf2flt.c 2015-08-27 16:42:51.599398857 +0200 @@ -638,6 +638,8 @@ case R_ARM_ABS32: relocation_needed = 1; break; + case R_ARM_NONE: + case R_ARM_PREL31: case R_ARM_REL32: case R_ARM_THM_PC11: case R_ARM_THM_PC22: --- host-elf2flt-21c6a41885ad544763ccd19883c1353f3b0b7a47/cygwin-elf.h 2012-10-04 04:32:38.000000000 +0200 +++ host-elf2flt-21c6a41885ad544763ccd19883c1353f3b0b7a47/cygwin-elf.h 2015-08-25 23:00:09.971202559 +0200 @@ -1882,6 +1882,7 @@ #define R_ARM_LDR_SBREL_11_0 35 #define R_ARM_ALU_SBREL_19_12 36 #define R_ARM_ALU_SBREL_27_20 37 +#define R_ARM_PREL31 42 /* 32 bit PLT address */ #define R_ARM_GNU_VTENTRY 100 #define R_ARM_GNU_VTINHERIT 101 #define R_ARM_THM_PC11 102 /* thumb unconditional branch */