GNU Arm Embedded Toolchain

Why there is eh_frame in strcmp.o?

Asked by Thomas Giesel

In the linker script for our project I added an error message that complains when some kinds of sections are found which I do not expect. One of them is eh_frame, because I thought this shouldn't be needed in a simple plain C program.

The code is compiled for Cortex-M3 and linked with --specs=nano.specs --specs=nosys.specs using 4_9-2015q1. I realized that there is one single eh_frame, which comes from arm-none-eabi/lib/armv7e-m/libg_nano.a(lib_a-strcmp.o). It looks like this object file is the only one in the library with an eh_frame.

It is the variant ./libc/machine/arm/strcmp-arm-tiny.S. I cannot figure out from the source code why this frame is in there. Maybe there's nothing bad with it, but I'd like to understand what it does and why it is the only file. Can you help me to understand it? Or is my assumption wrong, that eh_frame shouldn't be needed in a simple C program w/o exception handling?

Thank you!
Thomas

---------------
Full output:
arm-none-eabi-objdump -x ./lib_a-strcmp.o

./lib_a-strcmp.o: file format elf32-littlearm
./lib_a-strcmp.o
architecture: arm, flags 0x00000011:
HAS_RELOC, HAS_SYMS
start address 0x00000000
private flags = 5000000: [Version5 EABI]

Sections:
Idx Name Size VMA LMA File off Algn
  0 .text 00000014 00000000 00000000 00000034 2**1
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .data 00000000 00000000 00000000 00000048 2**0
                  CONTENTS, ALLOC, LOAD, DATA
  2 .bss 00000000 00000000 00000000 00000048 2**0
                  ALLOC
  3 .eh_frame 00000028 00000000 00000000 00000048 2**2
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
  4 .ARM.attributes 0000001c 00000000 00000000 00000070 2**0
                  CONTENTS, READONLY
SYMBOL TABLE:
00000000 l d .text 00000000 .text
00000000 l d .data 00000000 .data
00000000 l d .bss 00000000 .bss
00000000 l d .eh_frame 00000000 .eh_frame
00000000 l d .ARM.attributes 00000000 .ARM.attributes
00000000 g F .text 00000014 strcmp

RELOCATION RECORDS FOR [.eh_frame]:
OFFSET TYPE VALUE
0000001c R_ARM_REL32 .text

---------------
Checked if other object files contain this section type using:
arm-none-eabi-objdump -x *.o | grep " .eh_frame "
  3 .eh_frame 00000028 00000000 00000000 00000048 2**2

Question information

Language:
English Edit question
Status:
Solved
For:
GNU Arm Embedded Toolchain Edit question
Assignee:
No assignee Edit question
Solved by:
Thomas Giesel
Solved:
Last query:
Last reply:
Revision history for this message
Thomas Preud'homme (thomas-preudhomme) said : 		#1

Hi Thomas,

Unfortunately I only have part of the answer but hopefully that should be enough for you. The .eh_frame sections are created as a result of the gas directive .cfi_startproc. This explains why there is such section in our libraries. That being said, all functions written in assembly have these directive so I'm not sure why only strcmp has it.

Best regards.

Revision history for this message
Thomas Preud'homme (thomas-preudhomme) said : 		#2

Hi Thomas,

After reading header of section 8.1 at [1], I am wondering if it is not a size issue. Maybe function that are too big end up as .debug_frame (which are stripped in our builds) while the tiny variant is small enough to stay in a .eh_frame section. It might be worth considering compiling with -fasynchronous-unwind-tables. Bigger strcmp implementation (in libc.a) also have .eh_frame but I believe that is because they have .cfi_def_cfa_offset directive which create a relocation against .eh_frame section.

[1] http://refspecs.linuxfoundation.org/LSB_3.0.0/LSB-Core-generic/LSB-Core-generic/ehframechpt.html

Note that this is just a theory, it might be incorrect. Note also that GCC manpages mentions that exception handling might be needed for interoperability with C++ which is probably why there is some in newlib-nano.

Best regards.

Revision history for this message
Thomas Giesel (skoe) said : 		#3

Thank you for diving into the problem.

I wonder how eh_frame and debug_frame are related, despite the fact that they both have to do with unwinding. The first doubt comes in mind when I see that the sample gcc.ld writes eh_frame into flash but debug_frame isn't, apparently.

It seems to make sense that there are unwind tables for C++ compatibility. But all these assembly functions in machine/arm seem to be leaf functions, so they cannot call C++ code.

Regarding .cfi_startproc and .cfi_def_cfa_offset: It's true that there is cfi_startproc in all of these functions, while cfi_def_cfa_offset is in *some* of the strcmp functions, but not in, e.g., strcmp-arm-tiny.S, which is the function in question.

To summarize it: It looks like eh_frame is written to flash and debug_frame is not (what's what I think). strcmp-arm-tiny.S has eh_frame but no other function. This and many other functions are leaf functions and cannot call C++. This looks to me like it is either unnecessary that this function has an eh_frame or it should be necessary that all of them have one.

Is it correct that a plain C program (no C++ interop) never needs eh_frame? Then it is no harm for me for sure. However, it may be incorrect and may waste some program memory on small micro-controllers and it may be unwanted or incomplete for C++/C mixtures. If so, it may be worth to file a bug. But I don't even know where and what to write there :) Most probably newlib.

Best regards
Thomas

Revision history for this message
Thomas Preud'homme (thomas-preudhomme) said : 		#4

Hi Thomas,

As far as I know .debug_frame and .eh_frame are two side of the same coin. See -funwind-tables and -fasynchronous-unwind-tables. As you noticed .eh_frame will be loaded with the program while .debug_frame is for debugging only. Feel free to open a bug in Launchpad and hopefully somebody will look at it but note that we are a bit overwhelmed for now.

Best regards.

Revision history for this message
Thomas Giesel (skoe) said : 		#5

Yes, we have the same understanding of .debug_frame and .eh_frame. I'll file a bug for the sake of completeness, as it seems like there's something fishy there. I'm also quite busy at the moment, but possibly I'll be able to add some "research" results later.

Have a nice day.