How to retrieve the GCC version used to compile a given ELF executable?

Question

I'd like to retrieve the GCC version used to compile a given executable. I tried readelf but didn't get the information. Any thoughts?

Solution 1

It is normally stored in the comment section

strings -a <binary/library> |grep "GCC: ("

returns GCC: (GNU) X.X.X

strip -R .comment <binary>
strings -a <binary/library> |grep "GCC: ("

returns no output

It is not uncommon to strip the .comment (as well as .note) section out to reduce size via

strip --strip-all -R .note -R .comment <binary>
strip --strip-unneeded -R .note -R .comment <library>

Note: busybox strings specifies the -a option by default, which is needed for the .comment section

Edit: Contrary to Berendra Tusla's answer, it does not need to be compiled with any debugging flags for this method to work.

Binary example:

# echo "int main(void){}">a.c
# gcc -o a a.c -s
# strings -a a |grep GCC
GCC: (GNU) 4.3.4
# strip -R .comment a
# strings -a a |grep GCC
#

Object example:

# gcc -c a.c -s
# strings -a a.o |grep GCC
GCC: (GNU) 4.3.4
# strip -R .comment a.o
# strings -a a |grep GCC
#

Note the absence of any -g (debugging) flags and the presence of the -s flag which strips unneeded symbols. The GCC info is still available unless the .comment section is removed. If you need to keep this info intact, you may need to check your makefile (or applicable build script) to verify that -fno-ident is not in your $CFLAGS and the $STRIP command lacks -R .comment. -fno-ident prevents gcc from generating these symbols in the comment section to begin with.

Solution 2

To complete what others have said: it's not stored in the object (or exe) file, unless you compile with debugging information! (option -g). If you compile with debug info, you can get it back with readelf:

$ cat a.c
int main(void){ return 0; }
$ gcc a.c
$ readelf -wi a.out
$ gcc a.c -g       
$ readelf -wi a.out
Contents of the .debug_info section:

  Compilation Unit @ offset 0x0:
   Length:        0x42 (32-bit)
   Version:       2
   Abbrev Offset: 0
   Pointer Size:  4
 <0><b>: Abbrev Number: 1 (DW_TAG_compile_unit)
    < c>   DW_AT_producer    : (indirect string, offset: 0x0): GNU C 4.4.3 20100108 (prerelease)    
    <10>   DW_AT_language    : 1    (ANSI C)
    <11>   DW_AT_name        : a.c  
    <15>   DW_AT_comp_dir    : (indirect string, offset: 0x22): /tmp    
    <19>   DW_AT_low_pc      : 0x8048394    
    <1d>   DW_AT_high_pc     : 0x804839e    
    <21>   DW_AT_stmt_list   : 0x0  
 <1><25>: Abbrev Number: 2 (DW_TAG_subprogram)
    <26>   DW_AT_external    : 1    
    <27>   DW_AT_name        : (indirect string, offset: 0x27): main    
    <2b>   DW_AT_decl_file   : 1    
    <2c>   DW_AT_decl_line   : 1    
    <2d>   DW_AT_prototyped  : 1    
    <2e>   DW_AT_type        : <0x3e>   
    <32>   DW_AT_low_pc      : 0x8048394    
    <36>   DW_AT_high_pc     : 0x804839e    
    <3a>   DW_AT_frame_base  : 0x0  (location list)
 <1><3e>: Abbrev Number: 3 (DW_TAG_base_type)
    <3f>   DW_AT_byte_size   : 4    
    <40>   DW_AT_encoding    : 5    (signed)
    <41>   DW_AT_name        : int  

See how it says GNU C 4.4.3 20100108 (prerelease).

Solution 3

Yet another two ways (maybe a bit simpler) that I've just read about here: https://unix.stackexchange.com/questions/719/can-we-get-compiler-information-from-an-elf-binary

$ readelf -p .comment /usr/lib64/flash-plugin/libflashplayer.so

String dump of section '.comment':
  [     1]  GCC: (GNU) 4.3.2 20081105 (Red Hat 4.3.2-7)
  [    2e]  GCC: (GNU) 4.3.2
...

and

$ objdump -s --section .comment /usr/lib64/flash-plugin/libflashplayer.so

/usr/lib64/flash-plugin/libflashplayer.so:     file format elf64-x86-64

Contents of section .comment:
 0000 00474343 3a202847 4e552920 342e332e  .GCC: (GNU) 4.3.
 0010 32203230 30383131 30352028 52656420  2 20081105 (Red 
 0020 48617420 342e332e 322d3729 00004743  Hat 4.3.2-7)..GC
 0030 433a2028 474e5529 20342e33 2e320000  C: (GNU) 4.3.2..
 ...

Solution 4

This information is not stored in the compiled object (c).

Actually, for C code you're totally out of luck. However, for C++ code you may find some information from symbol versions. Some functions from C++ runtime libraries are version-specific, and are marked as such in object files. Try this:

readelf -Wa file.exe | grep 'GCC[[:alnum:]_.]*' --only-match | sort | uniq | tail -n 1

It won't show you the version of GCC used, however. What it shows is the version of symbols in runtime supplied to the compiler. Usually the runtime is that of a compiler shipment, and its version is not less than the one shown with the above command.

Solution 5

You can use the elfinfo utility. This also supports detecting the compiler versions of Go and FPC, in addition to GCC.

View more solutions

Comments

[Ilyes Gouta]

Alright, thank you guys! Can't figure out why such an important information doesn't make it into the ELF header. My target is actually an embedded Linux kernel.

[Konrad Rudolph]

What do you mean by “normally”? My compiler/version doesn’t store this information when compilation is done using the default options.

[Konrad Rudolph]

I’m using GCC 4.6.2 compiled on OS X but without any system-specific patches applied. It’s a vanilla GCC.

[Konrad Rudolph]

Nothing at all. If I include literal strings in the source code, those are correctly found by strings.

[jkoshy]

You would need to specify the -a option to strings, since the utility will not look inside the .comment section by default.

[technosaurus]

ahhh. I am using the busybox strings which sets -a by default. I'll update my answer.

[MarcH]

objdump -s --section .comment foo.o dumps the comment section on the screen

[tkocmathla]

Expanding on this a bit: the -p option doesn't exist in my ancient copy of readelf (from binutils 2.14), so I had to find the index of the .comment section, then hex dump it like so: readelf --hex-dump=$(readelf -S <so_file> | grep .comment | awk '{ print $1 }' | tr -d '[]') <so_file>

[michael]

Warning: in case it's not clear, the "strip -R" is destructive: $ man strip "-R sectionname - Remove any section named sectionname from the output file. (...) Note that using this option inappropriately may make the output file unusable."

[michael]

@technosaurus anything that "modifies" a value/file/variable is by definition (in computer science) "destructive"; it's just a technical term that has a precise meaning. Otherwise, yes, I agree the command does not "destroy" the file, not in the lay sense of the term. However, I'd also add that today, with binary files -- jars, libs, exe's -- anything that modifies the md5/sha1 would in effect make the file "unusable", in the sense of being untrustworthy & not to be used, yet not actually "unexecutable". (Many tools (eg pkg mgrs, build tools) therefore intentionally fail on this condition.)