view content of .obj file generated by MSVC compiler ?

JonB

@Vinoth-Rajendran4
I don't know how/what you expect to make a .obj/.o file "human-readable", as it most certainly is not, nor what there is of interest to you inside it? You can use a disassembler to view the source of the code inside it, and there may be dedicated tools provided by your compiler to view object files (e.g. MSVC may have something).

jsulm

@Vinoth-Rajendran4 said in view content of .obj file generated by MSVC compiler ?:

if we could make the content inside the object file, to be human readable , so that i could analyse ?

What do you mean exactly? You can see the assembly code if you like, but why would you if you have source code? You can also see the strings, but again: you can also see them in your source code. What do you want to analyse? What is the use case?

Vinoth Rajendran4

@jsulm : if i have a static variable in my code, can i see those entry in object file ?

jsulm

@Vinoth-Rajendran4 said in view content of .obj file generated by MSVC compiler ?:

can i see those entry in object file ?

What exactly do you want to see? The value of that variable? And why do you want to see it in object file?
I still fail to understand your use case.

Vinoth Rajendran4

@jsulm : I would like to know the value of the static variable , and where these variable will be placed in memory layout.
I was asked this question in an interview. So I would like to know about it.

jsulm

@Vinoth-Rajendran4 See https://www.geeksforgeeks.org/memory-layout-of-c-program/

Vinoth Rajendran4

@jsulm : memory layout, i am aware.
But like to know, if we could see the value of static variable in object file ?

jsulm

@Vinoth-Rajendran4 said in view content of .obj file generated by MSVC compiler ?:

if we could see the value of static variable in object file ?

Of couse you can - use a hex editor.
See "4. Let us initialize the static variable which will then be stored in the Data Segment (DS)" in the link I provided.

Kent-Dorfman

NM(1)                                                                                                      GNU Development Tools                                                                                                     NM(1)

NAME
       nm - list symbols from object files

SYNOPSIS
       nm [-A|-o|--print-file-name] [-a|--debug-syms]
          [-B|--format=bsd] [-C|--demangle[=style]]
          [-D|--dynamic] [-fformat|--format=format]
          [-g|--extern-only] [-h|--help]
          [-l|--line-numbers] [--inlines]
          [-n|-v|--numeric-sort]
          [-P|--portability] [-p|--no-sort]
          [-r|--reverse-sort] [-S|--print-size]
          [-s|--print-armap] [-t radix|--radix=radix]
          [-u|--undefined-only] [-V|--version]
          [-X 32_64] [--defined-only] [--no-demangle]
          [--plugin name]
          [--no-recurse-limit|--recurse-limit]]
          [--size-sort] [--special-syms]
          [--synthetic] [--with-symbol-versions] [--target=bfdname]
          [objfile...]

DESCRIPTION
       GNU nm lists the symbols from object files objfile....  If no object files are listed as arguments, nm assumes the file a.out.

       For each symbol, nm shows:

       ·   The symbol value, in the radix selected by options (see below), or hexadecimal by default.

       ·   The symbol type.  At least the following types are used; others are, as well, depending on the object file format.  If lowercase, the symbol is usually local; if uppercase, the symbol is global (external).  There are
           however a few lowercase symbols that are shown for special global symbols ("u", "v" and "w").

           "A" The symbol's value is absolute, and will not be changed by further linking.

           "B"
           "b" The symbol is in the BSS data section.  This section typically contains zero-initialized or uninitialized data, although the exact behavior is system dependent.

           "C" The symbol is common.  Common symbols are uninitialized data.  When linking, multiple common symbols may appear with the same name.  If the symbol is defined anywhere, the common symbols are treated as undefined
               references.

           "D"
           "d" The symbol is in the initialized data section.

           "G"
           "g" The symbol is in an initialized data section for small objects.  Some object file formats permit more efficient access to small data objects, such as a global int variable as opposed to a large global array.

           "i" For PE format files this indicates that the symbol is in a section specific to the implementation of DLLs.  For ELF format files this indicates that the symbol is an indirect function.  This is a GNU extension to the
               standard set of ELF symbol types.  It indicates a symbol which if referenced by a relocation does not evaluate to its address, but instead must be invoked at runtime.  The runtime execution will then return the value to
               be used in the relocation.

           "I" The symbol is an indirect reference to another symbol.

           "N" The symbol is a debugging symbol.

           "p" The symbols is in a stack unwind section.

           "R"
           "r" The symbol is in a read only data section.

           "S"
           "s" The symbol is in an uninitialized or zero-initialized data section for small objects.

JonB

@Kent-Dorfman
The OP asks about .obj files from MSVC. You sure UNIX/GNU nm is available and works on these?

Kent-Dorfman

@JonB if the object formt is COFF then it will work, even if OP has to build the utility themself. online info suggests that .obj format in windows is in fact COFF.

JonB

@Kent-Dorfman
I see, if you say so. Still not sure that OP would have a GNU nm utility available. FWIW, What COFF (windows .obj object file) viewers are available? for example states

I am only aware of 2:

dumpbin which is included with Visual Studio

PEView from http://wjradburn.com/software/

Kent-Dorfman

@JonB said in view content of .obj file generated by MSVC compiler ?:

Still not sure that OP would have a GNU nm utility available.

mingw provides the whole slew of gnu utilities as windows native executables. nm should be available, at which point the mingw exe can be used to process the windows native object file.

With a caveat that most folks would probably overlook: OP wants to process C++ object files, in which case the symbol names will probably be name-mangled, unless they were declared as extern "C" {}

JonB

@Kent-Dorfman said in view content of .obj file generated by MSVC compiler ?:

mingw provides the whole slew of gnu utilities as windows native executables. nm should be available,

Ooohhh, sorry, right, that makes sense!

Though I thought MinGW did .o not .obj files, I thought that meant MSVC. But what do I know?! :)

Chris Kawa

You don't need any unix or otherwise external tools. MSVC installation already comes with the dumpbin utility that lets you see various information about the structure and contents of COFF files. It also undecorates C++ function names, so no problem there either.

Vinoth Rajendran4

@Chris-Kawa : Thanks for the utility tool suggestion.

Vinoth Rajendran4

@Kent-Dorfman : Thanks for suggesting nm utility.

JonB

@JonB said in view content of .obj file generated by MSVC compiler ?:

(https://stackoverflow.com/questions/2262959/what-coff-windows-obj-object-file-viewers-are-available) for example states
I am only aware of 2:

dumpbin which is included with Visual Studio

PEView from http://wjradburn.com/software/