issue with c++ exceptions support + elf loading

[CookieDoughMixer]

When we are trying to build elf along with exceptions (stm32f4discovery elf config with uClib++ and exceptions enabled), some extra sections are getting created (without following the linker script).

abhishek@Linux:~/Work/public/nuttx_build/apps$ readelf -S --wide libapps.a
.
.
.
File: libapps.a(helloxx_main.cxx.home.abhishek.Work.public.nuttx_build.apps.examples.helloxx_1.o)
There are 34 section headers, starting at offset 0xa00:

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .group            GROUP           00000000 000034 000014 04     31  37  4
  [ 2] .text             PROGBITS        00000000 000048 000000 00  AX  0   0  1
  [ 3] .data             PROGBITS        00000000 000048 000000 00  WA  0   0  1
  [ 4] .bss              NOBITS          00000000 000048 000000 00  WA  0   0  1
  [ 5] .text._ZN11CHelloWorldD2Ev PROGBITS        00000000 000048 000002 00 AXG  0   0  2
  [ 6] .ARM.extab.text._ZN11CHelloWorldD2Ev PROGBITS        00000000 00004a 000000 00  AG  0   0  1
  [ 7] .ARM.exidx.text._ZN11CHelloWorldD2Ev ARM_EXIDX       00000000 00004c 000008 00 ALG  5   0  4
  [ 8] .rel.ARM.exidx.text._ZN11CHelloWorldD2Ev REL             00000000 0006b4 000008 08  IG 31   7  4
  [ 9] .rodata._ZN11CHelloWorld10HelloWorldEv.isra.0.str1.1 PROGBITS        00000000 000054 000056 01 AMS  0   0  1
  [10] .text._ZN11CHelloWorld10HelloWorldEv.isra.0 PROGBITS        00000000 0000ac 000018 00  AX  0   0  4
  [11] .rel.text._ZN11CHelloWorld10HelloWorldEv.isra.0 REL             00000000 0006bc 000018 08   I 31  10  4
  [12] .ARM.extab.text._ZN11CHelloWorld10HelloWorldEv.isra.0 PROGBITS        00000000 0000c4 000000 00   A  0   0  1
  [13] .ARM.exidx.text._ZN11CHelloWorld10HelloWorldEv.isra.0 ARM_EXIDX       00000000 0000c4 000008 00  AL 10   0  4
  [14] .rel.ARM.exidx.text._ZN11CHelloWorld10HelloWorldEv.isra.0 REL             00000000 0006d4 000008 08   I 31  13  4
  [15] .rodata.helloxx_main.str1.1 PROGBITS        00000000 0000cc 0000cf 01 AMS  0   0  1
  [16] .text.helloxx_main PROGBITS        00000000 00019c 000058 00  AX  0   0  4
  [17] .rel.text.helloxx_main REL             00000000 0006dc 000040 08   I 31  16  4
  [18] .ARM.extab.text.helloxx_main PROGBITS        00000000 0001f4 000000 00   A  0   0  1
  [19] .ARM.exidx.text.helloxx_main ARM_EXIDX       00000000 0001f4 000008 00  AL 16   0  4
  [20] .rel.ARM.exidx.text.helloxx_main REL             00000000 00071c 000010 08   I 31  19  4
  [21] .text.startup._GLOBAL__sub_I_helloxx_main PROGBITS        00000000 0001fc 000020 00  AX  0   0  4
  [22] .rel.text.startup._GLOBAL__sub_I_helloxx_main REL             00000000 00072c 000020 08   I 31  21  4
  [23] .ARM.extab.text.startup._GLOBAL__sub_I_helloxx_main PROGBITS        00000000 00021c 000000 00   A  0   0  1
  [24] .ARM.exidx.text.startup._GLOBAL__sub_I_helloxx_main ARM_EXIDX       00000000 00021c 000008 00  AL 21   0  4
  [25] .rel.ARM.exidx.text.startup._GLOBAL__sub_I_helloxx_main REL             00000000 00074c 000008 08   I 31  24  4
  [26] .init_array       INIT_ARRAY      00000000 000224 000004 04  WA  0   0  4
  [27] .rel.init_array   REL             00000000 000754 000008 08   I 31  26  4
  [28] .bss._ZL12g_HelloWorld NOBITS          00000000 000228 000004 00  WA  0   0  4
  [29] .comment          PROGBITS        00000000 000228 00004a 01  MS  0   0  1
  [30] .ARM.attributes   ARM_ATTRIBUTES  00000000 000272 00002e 00      0   0  1
  [31] .symtab           SYMTAB          00000000 0002a0 000320 10     32  41  4
  [32] .strtab           STRTAB          00000000 0005c0 0000f1 00      0   0  1
  [33] .shstrtab         STRTAB          00000000 00075c 0002a1 00      0   0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
  L (link order), O (extra OS processing required), G (group), T (TLS),
  C (compressed), x (unknown), o (OS specific), E (exclude),
  y (purecode), p (processor specific)

File: libapps.a(dummy.c.home.abhishek.Work.public.nuttx_build.apps.platform_1.o)
There are 9 section headers, starting at offset 0x16c:
.
.

But, as per the elf loader code, we are only considering one ARM.exidx section in up_init_exidx,

nuttx/binfmt/libelf/libelf_load.c

Lines 408 to 420 in 72f9bd1

	#ifdef CONFIG_ELF_EXIDX_SECTNAME
	exidx = elf_findsection(loadinfo, CONFIG_ELF_EXIDX_SECTNAME);
	if (exidx < 0)
	{
	binfo("elf_findsection: Exception Index section not found: %d\n",
	exidx);
	}
	else
	{
	up_init_exidx(loadinfo->shdr[exidx].sh_addr,
	loadinfo->shdr[exidx].sh_size);
	}
	#endif

Why are the other sections not considered? Also, why is the out file not following the linker script, why are new sections created?

I have integrated the elf loading (binfmt/libelf) in my project and I am trying to enabled cpp exceptions. I am stuck with the issue I have mentioned above. I couldn't check if the config works fine as I don't have stm32f4discovery board but I am able to verify that the same sections are getting created in nuttx too. Is this expected behavior? Is there a way to avoid these additional sections?

I have fixed some build issues when building the above config in the below PRs.

#11688
apache/nuttx-apps#2286

[CookieDoughMixer]

Also, to add, as I understand each text section has corresponding exidx and extab sections. Hence, wondering

1. how and why the new extra text sections are created without following the linker script
2. why are the additional exidx sections not taken care of during elf loading.

[acassis]

Thank you @abhishek-samsung !
I approved the first commit, but the second one seems incorrect

[CookieDoughMixer]

Hello @acassis , could you please help me with this issue? Are exceptions with elf loading working on any other ARM cortex M boards?

Also, I found that all the newly created sections have the SHF_GROUP flag. And its not handled in elf loading. Any guidance or reference on this would be very helpful.

[acassis]

Hi @abhishek-samsung I did a suggestion in your PR, maybe we could create a generic section that could be defined in the board linker script and that section will be just like an alias to the ARM section. I think this way we avoid polluting the generic linker script with arch specific sections. @xiaoxiang781216 @patacongo what do you think?

[xiaoxiang781216]

Since it's a common issue for all arm32 soc/chip, I would suggest that we should find a solution fix this problem for all board.