views:

358

answers:

1

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:

  1. What is the object file format generated by the MSVC2003 compiler?
  2. How can I disassemble that object file?

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.

Thanks!

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.

+1  A: 

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.

Michael Burr
@Michael:you're right -- though the actual code generated might change, the tools like dumpbin haven't changed significantly (older versions didn't handle all the latest instruction sets, but that's about it).
Jerry Coffin
I'll edit to add some more detail. The C source can be *anything* as far as I can tell - every object output in this entire project has the same behaviour.
Carl Norum
What does `file` tell you the type of that object file is?
Carl Norum
`file` 5.03 (from the GnuWin32 package) says: `test.obj; 80386 COFF executable not stripped - version 25970`
Michael Burr
@Carl: you might want to post the exact command line used to create the C-based `.obj`. Maybe some option is causing things to go sideways (you're not using the `/clr` switch, are you?).
Michael Burr
@Michael, that's a good question. I'll have to dig into the build system to figure out how to get that command line echoed. I expect `/clr` is not one of them though; these are EFI objects for building boot ROMs.
Carl Norum
@Michael - I updated the post with some command lines.
Carl Norum
@Carl: I think the problem is `/GL` - I'm updating the answer...
Michael Burr
@Michael, yeah just saw that in the documentation myself: ".obj files produced with /GL will not be available to such linker utilities as EDITBIN and DUMPBIN."
Carl Norum
Turning off the switch works! Thanks for the help! If anyone out there has an idea about how to disassemble the `/GL` format, I'd love to hear it!
Carl Norum