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