Wednesday, April 13, 2016

Object files in an executable in Linux

By Hường Hana 6:00 PM , , Leave a Comment

Is there a way to find the object files from which the current executable is generated in Linux (RHEL to be specific). I understand that one can use "nm" to find the exported symbols, "ldd" to find dependent shared object.

But I could not find command to find out the name of object (.o) files of which executable is composed of. Is it possible?

5 Answers

Answers 1

If it has been compiled with debugging infomation yes. Use gdb (man gdb) to find the infomation.

If it hasnt been compiled without debug infomation. You are out of luck.

Answers 2

The original names of the object files are not stored in the DWARF debugging information.

Each object file has a DW_TAG_compile_unit entry in the .debug_info section. This entry contains a reference to the "primary source file from which the compilation unit was derived", but not the name of the object file. The DWARF standard contains a list of the attributes that can be stored for each compilation unit (section 3.1.1, page number 44, pdf page 58).

You can view the information that is stored with the following command:

$ readelf --debug-dump=info --dwarf-depth=1 hw

Output:

Contents of the .debug_info section: <some compilation units removed>          Compilation Unit @ offset 0x133:    Length:        0x8b (32-bit)    Version:       4    Abbrev Offset: 0x64    Pointer Size:  4  <0><13e>: Abbrev Number: 1 (DW_TAG_compile_unit)     <13f>   DW_AT_producer    : (indirect string, offset: 0x131): GNU C11 5.3.0 -mtune=generic -march=pentiumpro -g     <143>   DW_AT_language    : 12      (ANSI C99)     <144>   DW_AT_name        : (indirect string, offset: 0x163): hw.c     <148>   DW_AT_comp_dir    : (indirect string, offset: 0x168): /home/mikel/src/hw     <14c>   DW_AT_low_pc      : 0x80483db     <150>   DW_AT_high_pc     : 0x2e     <154>   DW_AT_stmt_list   : 0xea  <1><158>: ... <some compilation units removed>

Answers 3

In addition to nullptr, "shared object" refers to other shared libraries (linked), not to original objects (not linked)

Answers 4

You can also use objdump (as long as the executable and objects were compiled with debugging information):

# gcc -g -c -o /tmp/some_object.o /tmp/some_object.c # gcc -g -o /tmp/file /tmp/file.c /tmp/some_object.o # objdump -g /tmp/file | awk 'BEGIN{out=0} /Directory Table/{out=1} /Line Number Statements/{out=0} {if(out){print $0}}'  The Directory Table (offset 0x1b):   1     /tmp   The File Name Table (offset 0x21):   Entry Dir     Time    Size    Name   1     1       0       0       file.c   The Directory Table (offset 0x5a):   1     /tmp   The File Name Table (offset 0x60):   Entry Dir     Time    Size    Name   1     1       0       0       some_object.c

awk is used just to extract the relevant info (if you don't use, you'll get the full debug info in the executable and objects).

Answers 5

An object file translates to an executable after linking. If the linking is shared, then you can get that via shared libraries ( ldd ). However if the linking is static, then there is only way i.e. via debug info. You can install debuginfo packages in RHEL (or Fedora for that matter). Here are the instructions

And then use gdb info sources as described here:

This would give you a list of Source Files. But to actually get the object files, you need to look deeper into the build tools (rpmbuild). And to actually run rpmbuild you would need the Source RPM package, which you can obtain using the instructions listed here:

Now you can build the package yourselves, and dissect which .o file resulted into the executable.

I hope that helps.

If You Enjoyed This, Take 5 Seconds To Share It

0 comments:

Post a Comment