RFC: Add initial support for .NET Core dlls to objdump

Nick Clifton nickc@redhat.com
Tue Jul 23 14:28:00 GMT 2019

Hi Omair,

> This might be a stupid question,

Actually it is not stupid at all...

> but how does the test deal with
> regressions in dll parsing? It seems to me like the test would pass even
> if objudmp can't parse System.Runtime.dll. The "file format not
> recognized" is the same error that a objdump built without the fix
> prints out:
> $ objdump -x /usr/lib64/dotnet/shared/Microsoft.NETCore.App/2.1.12/System.Runtime.dll
> objdump: /usr/lib64/dotnet/shared/Microsoft.NETCore.App/2.1.12/System.Runtime.dll: file format not recognized

Well bananas.  I had not considered that.

I think that what we need to do is to extend gentestdlls.c so that
it generates a normal x86 PE dll file as well.  Then the test can
be extended to check this file first.  If the target objdump is
able to parse this file, then it should be able to parse the other
two files as well.  If it cannot then there is an error.  (Actually
32-bit PE toolchains may only be able to parse one of the new .NET
PE dlls).

>>   additions to the header files will now work on targets which only
>>   support 32-bit PE format files.
> Ah, thank you. Is there a way I can discover this myself (for next
> time)? Would ./configure --enable-targets=all flag this for me?

Nope.  You need a target that includes the 32-bit PE header but not
the 64-bit PE header.  I used "./configure --target=i686-pc-cygwin".


More information about the Binutils mailing list