Why nm hides .rela.eh_frame and .rela.text in .o files?

Question

I'm trying to recreate the behaviour of the command nm in C, and although I was successful getting the names of the symbols and sections, I find out that some extra names appear in my version.

$> ./my_nm -a obj.o

0000000000000000 b .bss
0000000000000000 n .comment
0000000000000000 d .data
0000000000000000 r .eh_frame
0000000000000000 n .note.GNU-stack
0000000000000000 r .note.gnu.property
0000000000000000 d .rela.eh_frame
0000000000000000 d .rela.text
0000000000000000 t .text
                 U _GLOBAL_OFFSET_TABLE_
0000000000000000 T elf64_syms
0000000000000000 a elf64_syms.c
                 U malloc

$> nm -a obj.o

0000000000000000 b .bss
0000000000000000 n .comment
0000000000000000 d .data
0000000000000000 r .eh_frame
0000000000000000 n .note.GNU-stack
0000000000000000 r .note.gnu.property
0000000000000000 t .text
                 U _GLOBAL_OFFSET_TABLE_
0000000000000000 T elf64_syms
0000000000000000 a elf64_syms.c
                 U malloc

I did some research about them and found that they are some sort of a reference to a section or symbol. I wonder if there is anything special about them. If so, how can I differentiate between them and other .rela...?

score 4 · Accepted Answer · answered Apr 18 '22 at 02:49

I find out that some extra names appear in my version.

The Linux nm version uses libbfd, which maps different object file formats into its own internal data model, and then nm prints that internal representation.

libbfd predates ELF by at least 2 decades, and its internal model is inadequate for representing complexities of the ELF format (things get lost in translation).

For this reason, one generally shouldn't use nm, objdump and other libbfd-based tools to examine ELF files (use readelf instead, which shows things as they are without translation losses).

So, you've done nothing wrong and your version of nm is better.

Why nm hides .rela.eh_frame and .rela.text in .o files?

1 Answers1