I'm seeing what I think is strange behaviour from object files output by the Microsoft Visual Studio 2003 tools. The file utility tells me:
asmfile.obj: 80386 COFF executable not stripped - version 30821
For objects created by the assembler, but for objects coming from C files, I get just:
cfile.obj: data
Using Microsoft's dumpbin utility and the objdump I got from cygwin, I can disassemble the assembly-built file, but I get no useful results from either utility for the C-built files.
I have a couple of questions related to this difference:
I am particularly interested in getting the disassembly in AT&T syntax - I'm doing a port of a large source base to make it work with GCC, and I would like to use this method as a shortcut for some of the inline assembly routines in the project.
Edit: Adding some more information.
When I run dumpbin on one of these files gives me no results:
C:\> dumpbin /disasm Func.obj
Microsoft (R) COFF/PE Dumper Version 7.10.6030
Copyright (C) Microsoft Corporation. All rights reserved.
Dump of file Func.obj
FileType: ANONYMOUS OBJECT
With objdump, it gives:
$ objdump -d Func.obj
objdump: Func.obj: File truncated
On the files built from assembly, I get reasonable results.
Edit again: Adding command line information.
The assembly files are built with a command line resembling the following:
ml -nologo -W3 -WX -c -coff -FoAssemblyFile.obj -Zi -Cx AssemblyFile.asm
ml when executed by itself says:
Microsoft (R) Macro Assembler Version 6.15.8803
Copyright (C) Microsoft Corp 1981-2000. All rights reserved.
The C files are built with the following command:
cl -nologo -W4 -WX -Gs32768 -GX -Gy -c -FdCFile.pdb -FoCFile.obj -Zi
-Gm -O1 -Oy- -Gy -GL -X CFile.c
There are some -I and -D options passed to ml and to cl, but I've omitted them for brevity here. The cl options are described here.
Edit based on the cl command line options being added to the question:
I think the problem is the use of the /GL option, which specifies that link-time code generation optimization will be done. from a doc page on that option:
obj files produced with /GL will not be available to such linker utilities as EDITBIN and DUMPBIN.
Using this option causes the compiler to generate .obj files that the linker can perform program-wide optimization on - apparently the file format is proprietary (maybe it's documented somewhere, but I suspect not).
The docs for /GL (also known as "whole program optimization", "link-time code generation", or LTCG) contain several warnings about interoperability of the .obj files or libraries containing such objects files.
Original answer:
What exactly is in the C source for the .obj file you're trying to disassemble? I get the following using dumpbin /disasm test.obj for a simple 'hello world' program:
Microsoft (R) COFF/PE Dumper Version 8.00.50727.42
Copyright (C) Microsoft Corporation. All rights reserved.
Dump of file test.obj
File Type: COFF OBJECT
_main:
00000000: 55 push ebp
00000001: 8B EC mov ebp,esp
00000003: 6A 01 push 1
00000005: 68 00 00 00 00 push offset $SG4665
0000000A: E8 00 00 00 00 call _printf
0000000F: 83 C4 08 add esp,8
00000012: 33 C0 xor eax,eax
00000014: 3B EC cmp ebp,esp
00000016: E8 00 00 00 00 call __RTC_CheckEsp
0000001B: 5D pop ebp
0000001C: C3 ret
Summary
7AC .debug$S
30 .debug$T
2F .drectve
4 .rdata
4 .rtc$IMZ
4 .rtc$TMZ
1D .text
Note: this is using an .obj file compiled by and a dumpbin provided by VS2005, but I can't imagine this stuff would have changed much from VS2003.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With