[Buildroot] elf2flt .ARM.exidx and .ARM.extab section handling

[Buildroot] elf2flt .ARM.exidx and .ARM.extab section handling

[Douglas RAILLARD]

Hi everybody,

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

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



--- 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 at __exidx_start = .);
+	.ARM.exidx   : { *(.ARM.exidx* .gnu.linkonce.armexidx.*) } > flatmem
+	PROVIDE_HIDDEN (@SYMBOL_PREFIX at __exidx_end = .);
+	
 	. = ALIGN(0x10) ;
 	@SYMBOL_PREFIX at _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 */





-- 

Douglas RAILLARD

[Buildroot] elf2flt .ARM.exidx and .ARM.extab section handling

[Thomas Petazzoni]

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 Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] elf2flt .ARM.exidx and .ARM.extab section handling

[Douglas RAILLARD]

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


-- 

Douglas RAILLARD

[Buildroot] elf2flt .ARM.exidx and .ARM.extab section handling

[Thomas Petazzoni]

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
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] elf2flt .ARM.exidx and .ARM.extab section handling

[Waldemar Brodkorb]

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

[Buildroot] elf2flt .ARM.exidx and .ARM.extab section handling

[Douglas RAILLARD]

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

-- 

Douglas RAILLARD

[Buildroot] elf2flt .ARM.exidx and .ARM.extab section handling

[Thomas Petazzoni]

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
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com