object code from which compiler

[ajm]

Hi All,

given an object file is there any way (or tool) to determine which
compiler created it ?

tia,
A.

 

[Kenneth Brody]

Hi All,

given an object file is there any way (or tool) to determine which
compiler created it ?

No.

While some object file formats may support a method for the compiler to
insert such information, and some compilers creating that file format
may actually insert that information, there is no way in general to get
information about the compiler itself.

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[Simon Biber]

Hi All,

given an object file is there any way (or tool) to determine which
compiler created it ?

The format of the object file may be different for each implementation
or platform. Some do record the compiler name, some don't. One of my
object files has the following string embedded, which I extracted with
the "strings" and "grep" commands.

$ strings RGBColour.obj | grep compiler
@-compiler:"C:\Program Files\Microsoft Visual Studio .NET
2003\Vc7\bin\c2.dll"

Just determining the file format may help. Try the "file" command.

$ file devcpp/main.o
devcpp/main.o: 80386 COFF executable not stripped - version 30821

$ file linux2/main.o
linux2/main.o: ELF 32-bit LSB relocatable, Intel 80386, version 1
(SYSV), not stripped

$ file vsnet/main.obj
vsnet/main.obj: data

It recognised the Windows and Linux object files produced by GCC, but
unfortunately it didn't recognise the VS.NET object file.

 

[Michael Wojcik]

given an object file is there any way (or tool) to determine which
compiler created it ?

There is no standard mechanism for doing so; the standard does not
even require that there be an "object file", though it does discuss
the result of translation, which is probably close enough. (There
are implementations which do not treat the result of translation as
a file of "object code", exactly, but close enough.)

[OT] In general, there's no way to do this. Some implementations may
include identifying information in their output, but no doubt there
are others which do not. You could analyze sample outputs of various
implementations and devise heuristics to guess which implementation
produced which output, but you'd never have anything better than a
heuristic solution, and I suspect it wouldn't be terribly accurate in
the general case.

 

[ajm]

Yup from what I could gather it seems that (naturally enough) object
files mostly contain arch dependent info (e.g., stuff for linking and
loading etc.) I had a look through some details of ELF and COFF
formats etc. and could see nothing in their structures that would hint
at compiler origin.

It is interesting to see Simon's strings/grep example as the MS formats
seem to contain more info compared to, say, ELF (e.g., OS versions
etc.).

Thx, All.

A.

 

[Roger Leigh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I had a look through some details of ELF and COFF formats etc. and
could see nothing in their structures that would hint at compiler
origin.

The ELF section names give a heavy hint about which toolchain was used
(GCC 4.0 in this case). If the object code is not stripped, there
will be vastly more information to look into.

$ objdump -h /bin/bash

/bin/bash: file format elf32-powerpc

Sections:
Idx Name Size VMA LMA File off Algn
0 .interp 0000000d 10000154 10000154 00000154 2**0
CONTENTS, ALLOC, LOAD, READONLY, DATA
1 .note.ABI-tag 00000020 10000164 10000164 00000164 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
2 .hash 00002f28 10000184 10000184 00000184 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
3 .dynsym 00007c10 100030ac 100030ac 000030ac 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
4 .gnu.liblist 00000050 1000acbc 1000acbc 0000acbc 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
5 .gnu.conflict 00000240 1000ad0c 1000ad0c 0000ad0c 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
6 .gnu.version 00000f82 10012346 10012346 00012346 2**1
CONTENTS, ALLOC, LOAD, READONLY, DATA
7 .gnu.version_r 00000080 100132c8 100132c8 000132c8 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
8 .rela.dyn 00000060 10013348 10013348 00013348 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
9 .rela.plt 0000084c 100133a8 100133a8 000133a8 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
10 .init 00000028 10013bf4 10013bf4 00013bf4 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
11 .text 000865b4 10013c1c 10013c1c 00013c1c 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
12 .fini 00000020 1009a1d0 1009a1d0 0009a1d0 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
13 .rodata 00014fc8 1009a1f0 1009a1f0 0009a1f0 2**3
CONTENTS, ALLOC, LOAD, READONLY, DATA
14 .sdata2 00000000 100af1b8 100af1b8 000af1b8 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
15 .eh_frame_hdr 0000002c 100af1b8 100af1b8 000af1b8 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
16 .data 00005004 100bf1e4 100bf1e4 000af1e4 2**2
CONTENTS, ALLOC, LOAD, DATA
17 .eh_frame 000000bc 100c41e8 100c41e8 000b41e8 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
18 .got2 00000010 100c42a4 100c42a4 000b42a4 2**0
CONTENTS, ALLOC, LOAD, DATA
19 .dynamic 000000d8 100c42b4 100c42b4 000b42b4 2**2
CONTENTS, ALLOC, LOAD, DATA
20 .ctors 00000008 100c438c 100c438c 000b438c 2**2
CONTENTS, ALLOC, LOAD, DATA
21 .dtors 00000008 100c4394 100c4394 000b4394 2**2
CONTENTS, ALLOC, LOAD, DATA
22 .jcr 00000004 100c439c 100c439c 000b439c 2**2
CONTENTS, ALLOC, LOAD, DATA
23 .got 00000014 100c43a0 100c43a0 000b43a0 2**2
CONTENTS, ALLOC, LOAD, CODE
24 .sdata 0000017c 100c43b4 100c43b4 000b43b4 2**2
CONTENTS, ALLOC, LOAD, DATA
25 .sdynbss 0000001c 100c4530 100c4530 000b4530 2**3
CONTENTS, ALLOC, LOAD, DATA
26 .sbss 00000a84 100c454c 100c454c 000b454c 2**3
CONTENTS, ALLOC, LOAD, DATA
27 .plt 00000894 100c4fd0 100c4fd0 000b4fd0 2**2
CONTENTS, ALLOC, LOAD, CODE
28 .bss 00004224 100c5868 100c5868 000b5864 2**3
ALLOC
29 .dynstr 00007696 100d5864 100d5864 000b5864 2**0
CONTENTS, ALLOC, LOAD, READONLY, DATA
30 .gnu.prelink_undo 00000594 00000000 00000000 000bcefc 2**2
CONTENTS, READONLY

$ objdump -s -j .note.ABI-tag /bin/bash

/bin/bash: file format elf32-powerpc

Contents of section .note.ABI-tag:
10000164 00000004 00000010 00000001 474e5500 ............GNU.
10000174 00000000 00000002 00000002 00000000 ................

$ objdump -p /bin/bash

/bin/bash: file format elf32-powerpc

Program Header:
PHDR off 0x00000034 vaddr 0x10000034 paddr 0x10000034 align 2**2
filesz 0x00000120 memsz 0x00000120 flags r-x
INTERP off 0x00000154 vaddr 0x10000154 paddr 0x10000154 align 2**0
filesz 0x0000000d memsz 0x0000000d flags r--
LOAD off 0x00000000 vaddr 0x10000000 paddr 0x10000000 align 2**16
filesz 0x000af1e4 memsz 0x000af1e4 flags r-x
LOAD off 0x000af1e4 vaddr 0x100bf1e4 paddr 0x100bf1e4 align 2**16
filesz 0x00006680 memsz 0x0000a8a8 flags rwx
LOAD off 0x000b5864 vaddr 0x100d5864 paddr 0x100d5864 align 2**16
filesz 0x00007696 memsz 0x00007696 flags rw-
DYNAMIC off 0x000b42b4 vaddr 0x100c42b4 paddr 0x100c42b4 align 2**2
filesz 0x000000d8 memsz 0x000000d8 flags rw-
NOTE off 0x00000164 vaddr 0x10000164 paddr 0x10000164 align 2**2
filesz 0x00000020 memsz 0x00000020 flags r--
EH_FRAME off 0x000af1b8 vaddr 0x100af1b8 paddr 0x100af1b8 align 2**2
filesz 0x0000002c memsz 0x0000002c flags r--
STACK off 0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**2
filesz 0x00000000 memsz 0x00000000 flags rwx

Dynamic Section:
NEEDED libncurses.so.5
NEEDED libdl.so.2
NEEDED libc.so.6
INIT 0x10013bf4
FINI 0x1009a1d0
HASH 0x10000184
STRTAB 0x100d5864
SYMTAB 0x100030ac
STRSZ 0x7689
SYMENT 0x10
DEBUG 0x0
PLTGOT 0x100c4fd0
PLTRELSZ 0x84c
PLTREL 0x7
JMPREL 0x100133a8
RELA 0x10013348
RELASZ 0x8ac
RELAENT 0xc
VERNEED 0x100132c8
VERNEEDNUM 0x2
VERSYM 0x10012346
0x6ffffef9 0x1000acbc
0x6ffffdf7 0x50
0x6ffffef8 0x1000ad0c
0x6ffffdf6 0x240

Version References:
required from libdl.so.2:
0x0d696911 0x00 07 GLIBC_2.1
0x0d696910 0x00 06 GLIBC_2.0
required from libc.so.6:
0x0d696913 0x00 05 GLIBC_2.3
0x0d696911 0x00 04 GLIBC_2.1
0x0d696912 0x00 03 GLIBC_2.2
0x0d696910 0x00 02 GLIBC_2.0

It is interesting to see Simon's strings/grep example as the MS formats
seem to contain more info compared to, say, ELF (e.g., OS versions
etc.).

$ file /bin/bash
/bin/bash: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (SYSV), for GNU/Linux 2.2.0, dynamically linked (uses shared libs), stripped

There is no OS version, just the ELF machine and OS identifier. I'm
not sure quite how useful the OS version would be; the DT_NEEDED
library requirements and symbol versioning are quite sufficient. It's
not like the ELF format changes with new versions of the Linux kernel
or GNU libc...


Regards,
Roger

- --
Roger Leigh
Printing on GNU/Linux? http://gimp-print.sourceforge.net/
Debian GNU/Linux http://www.debian.org/
GPG Public Key: 0x25BFB848. Please sign and encrypt your mail.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>

iD8DBQFDFOMDVcFcaSW/uEgRAjrBAKC5ltrZCvfRf3UoL6b/mu3T+jYMaACgwKIJ
wQjzEgri7cLW0Ebp5zm5VBU=
=Rfrf
-----END PGP SIGNATURE-----

 

[E. Robert Tisdale]

Given an object file, is there any way (or tool)
to determine which compiler created it?

Gererally, no but:

> cat f.c

void f(void) {
}

> gcc -Wall -std=c99 -pedantic -c f.c
> strings -a f.o

GCC: (GNU) 4.0.0 20050519 (Red Hat 4.0.0-8)
.symtab
.strtab
.shstrtab
.text
.data
.bss
.comment
.note.GNU-stack

 

[Simon Biber]

$ strings RGBColour.obj | grep compiler
@-compiler:"C:\Program Files\Microsoft Visual Studio .NET
2003\Vc7\bin\c2.dll"

[snip]

Replying to myself: in addition, as Bob Tisdale pointed out, the -a
option on strings is useful.

$ strings -a linux2/main.o | grep GCC
GCC: (GNU) 3.4.4 20050721 (Red Hat 3.4.4-2)