How to determine an assembly's target platform?

  • Thread starter Thread starter Object01
  • Start date Start date
O

Object01

We're working with some benchmarks designed to test x86 vs. x64
performance (both on a x64 system). To ensure that our assemblies are
loaded as x86 or x64, we specifically target our builds to the
appropriate platform, avoiding using the "Any CPU" setting. (It's my
understanding that on an x64 system, the runtime will JIT an "Any CPU"
assembly as x64 if it's able.)

All this raised an interesting question: given an arbitrary .NET
assembly, how can I tell how it was compiled? ILDASM shows me the PE
header, and I've found sections labeled "PE Optional Header (64 bit)"
in assemblies specifically targeted to x64. But assemblies targeted
to "Any CPU" -and- assemblies targeted to x86 seem to have "PE
Optional Header (32 bit)", leaving some ambiguity. Is there a sure-
fire way to tell? A flag among all that hex, perhaps?
 
Object01 said:
We're working with some benchmarks designed to test x86 vs. x64
performance (both on a x64 system). To ensure that our assemblies are
loaded as x86 or x64, we specifically target our builds to the
appropriate platform, avoiding using the "Any CPU" setting. (It's my
understanding that on an x64 system, the runtime will JIT an "Any CPU"
assembly as x64 if it's able.)

All this raised an interesting question: given an arbitrary .NET
assembly, how can I tell how it was compiled? ILDASM shows me the PE
header, and I've found sections labeled "PE Optional Header (64 bit)"
in assemblies specifically targeted to x64. But assemblies targeted
to "Any CPU" -and- assemblies targeted to x86 seem to have "PE
Optional Header (32 bit)", leaving some ambiguity. Is there a sure-
fire way to tell? A flag among all that hex, perhaps?
Click to expand...

If you done the ildasm, you can see that .corflags is the relevant
field:

..corflags 0x00000001 // ILONLY

versus:

..corflags 0x00000003 // ILONLY 32BITREQUIRED

It's part of the CLI header, 'Flags' field. The CLI header is pointed to
by the an entry in the PE header directories, that follow PE optional
header. It's the 15th (RVA,Size) pair (aka directory entry) in that
list. The relevant details are in the ECMA 335 specification.

-- Barry
 
We're working with some benchmarks designed to test x86 vs. x64
performance (both on a x64 system). To ensure that our assemblies are
loaded as x86 or x64, we specifically target our builds to the
appropriate platform, avoiding using the "Any CPU" setting. (It's my
understanding that on an x64 system, the runtime will JIT an "Any CPU"
assembly as x64 if it's able.)

All this raised an interesting question: given an arbitrary .NET
assembly, how can I tell how it was compiled? ILDASM shows me the PE
header, and I've found sections labeled "PE Optional Header (64 bit)"
in assemblies specifically targeted to x64. But assemblies targeted
to "Any CPU" -and- assemblies targeted to x86 seem to have "PE
Optional Header (32 bit)", leaving some ambiguity. Is there a sure-
fire way to tell? A flag among all that hex, perhaps?
Click to expand...

I think I found a solution at http://blogs.msdn.com/gauravseth/archive/2006/03/07/545104.aspx.
The PETYPE and 32BIT flags can be used to determine the targeted
platform.
 
If you done the ildasm, you can see that .corflagsis the relevant
field:

.corflags0x00000001 // ILONLY

versus:

.corflags0x00000003 // ILONLY 32BITREQUIRED

It's part of the CLI header, 'Flags' field. The CLI header is pointed to
by the an entry in the PE header directories, that follow PE optional
header. It's the 15th (RVA,Size) pair (aka directory entry) in that
list. The relevant details are in the ECMA 335 specification.

-- Barry

--http://barrkel.blogspot.com/
Click to expand...

Am I interpreting ECMA 335 correctly when it says ($24.1) that ILONLY
should be ignored when read? By this reading, why would ILONLY ever
be 0, as it is in so many of the assemblies I've examined?
 
Am I interpreting ECMA 335 correctly when it says ($24.1) that ILONLY
should be ignored when read? By this reading, why would ILONLY ever
be 0, as it is in so many of the assemblies I've examined?
Click to expand...

AFAIK, in e.g. C++/CLI assembly with mixed native code (/clr), it won't
necessarily be present.

-- Barry
 
Back
Top