What Do the .Eh_Frame and .Eh_Frame_Hdr Sections Store, Exactly

What do the .eh_frame and .eh_frame_hdr sections store, exactly?

Please, see cfi-directives

It should cover history and theory of most of the sections in question.

About eh_frame, it contains exception unwinding and source language information. Each entry in this section is represented by single CFI (call frame information )

see, eh_frame in linuxfoundation

eh_frame_hdr, is used by c++ runtime code to access the eh_frame. That means, it contains the pointer and binary search table to efficiently retrieve the information from eh_frame.

Now, in case you want to see how you read/write this sections then I suggest take a look at following linker code.

(look for EhFrame.cpp, EhFrameHdr.cpp and EhFrameReader.cpp )

Good luck !!

gcc error compiling file

You need to say gcc -o notesearch notesearch.c. Otherwise, you are OUTPUTTING (-o) to the .c file, which is not good. Also, you may want to consider compiling with these other flags:

-Wall: Warn All, very useful.
-Werror: Again, very useful.
-g: This is my favorite flag. It compiles with debug symbols, so that you can start you program in gdb (Gnu DeBugger) and then examine what is happening, change values of variables during execution, and generally debug it. gdb is VERY helpful.

build error related to g++ -c flag

In your first case, without -c, your first g++ invocation generates a fully linked executable misleadingly named "app.o". (Try typing "file ./app.o" to describe the file in both cases. That might be interesting.) You will be able to run it. (Type ./app.o)

With the -c flag, that g++ invocation just generates the object code and that is suitable for a further link stage (as you observe).

I am getting the error: ld returned 1 exit status while trying to use make

You should add -c option to create an object file instead of executable binary.

find_bits.o: find_bits.c
    gcc -c -g -ansi -pedantic -Wall find_bits.c -o find_bits.o

CLR have fat or small exception frame?

This is covered in partition II section 25.4.5 of ECMA-335.

If CorILMethod_Sect_FatFormat bit (0x40) is set in the Kind field (the first byte of the structure) then you should use fat, otherwise small. The Kind field can be accessed via Small.SectSmall.Kind or Fat.SectFat.Kind, either should work.

Getting tons of errors when compiling a C program

The problem is in the command line: gcc -Wall -o -g ink ink.c

The -o argument must be followed by the name of the output file, so -g is used for that, and gcc sees ink (the executable produced by a previous command) as a binary module to link along with the object module compiled from ink.c and the C library, hence all the duplicate internal symbols.

Use this command:

gcc -Wall -g -o ink ink.c

Note also these problems in your code:

• relying on the contents of buff after the last call to fgets() is incorrect, especially if the file happens to be empty. You should instead convert each and every line successfully read and use the last conversion.

• you must call fseek(fp1, 0L, SEEK_CUR) before switching from reading the file to writing to it.

• char temp[10]; is not large enough to convert all possible int values. You should make the array larger and use snprintf for safety.

---

Related Topics