Re: func_win32_import_lib_p when file is missing

[Peter Rosin]

On 2012-10-07 14:48, Gary V. Vaughan wrote:
> Hi Peter,
> 
> On Oct 7, 2012, at 4:37 PM, Peter Rosin <address@hidden> wrote:
>> On 2012-10-07 06:04, Gary V. Vaughan wrote:
>>> On 7 Oct 2012, at 06:53, Peter Rosin <address@hidden> wrote:
>>>> objdump doesn't output "import" for me, at least not for any
>>>> import lib I have given it. Chunk?
>>>>
>>>> # func_win32_import_lib_p ARG
>>>> # True if ARG is an import lib, as indicated by $file_magic_cmd
>>>> func_win32_import_lib_p ()
>>>> {
>>>>   $debug_cmd
>>>>
>>>>   case `eval $file_magic_cmd \"\$1\" 2>/dev/null | $SED -e 10q` in
>>>>   *import*) : ;;
>>>>   *) false ;;
>>>>   esac
>>>> }
>>>
>>> Does '$OBJDUMP -f' output anything that can be used to distinguish an
>>> import library?
>>
>> "objdump -f" output from normal static lib:
>> --------------8<---------------
>> In archive ../msvc/tests/testsuite.dir/035/.libs/hello.lib:
>>
>> libhello_la-foo.obj:     file format pe-i386
>> architecture: i386, flags 0x0000003d:
>> HAS_RELOC, HAS_LINENO, HAS_DEBUG, HAS_SYMS, HAS_LOCALS
>> start address 0x00000000
>>
>> libhello_la-hello.obj:     file format pe-i386
>> architecture: i386, flags 0x0000003d:
>> HAS_RELOC, HAS_LINENO, HAS_DEBUG, HAS_SYMS, HAS_LOCALS
>> start address 0x00000000
>> --------------8<---------------
>>
>> And from an import lib:
>>
>> --------------8<---------------
>> In archive ../msvc/tests/testsuite.dir/034/.libs/hello.dll.lib:
>>
>> hello-2.dll:     file format pe-i386
>> architecture: i386, flags 0x0000003d:
>> HAS_RELOC, HAS_LINENO, HAS_DEBUG, HAS_SYMS, HAS_LOCALS
>> start address 0x00000000
>>
>> hello-2.dll:     file format pe-i386
>> architecture: i386, flags 0x0000003d:
>> HAS_RELOC, HAS_LINENO, HAS_DEBUG, HAS_SYMS, HAS_LOCALS
>> start address 0x00000000
>>
>> hello-2.dll:     file format pe-i386
>> architecture: i386, flags 0x0000003d:
>> HAS_RELOC, HAS_LINENO, HAS_DEBUG, HAS_SYMS, HAS_LOCALS
>> start address 0x00000000
>>
>> hello-2.dll:     file format pei-i386
>> architecture: i386, flags 0x00000018:
>> HAS_DEBUG, HAS_SYMS
>> start address 0x00000000
>>
>> hello-2.dll:     file format pei-i386
>> architecture: i386, flags 0x00000018:
>> HAS_DEBUG, HAS_SYMS
>> start address 0x00000000
>>
>> hello-2.dll:     file format pei-i386
>> architecture: i386, flags 0x00000018:
>> HAS_DEBUG, HAS_SYMS
>> start address 0x00000000
>> --------------8<---------------
>>
>> I don't imagine any of the differences to be really useful. I don't
>> know though... pe-i386 vs. pei-i386 looks promising, but I don't
>> possess enough PE-COFF-fuu to tell for sure. I think it would
>> have been used previously if it really did work?
> 
> Am I crazy, or isn't it a matter of file naming conventions here?
> 
> If all import libs are named foo.dll.lib, and regular dlls are named foo.dll,
> then it's easy to write a case statement to distinguish the two :)

Alas, that's too naive.  You really have to look *in* the file to know,
and there are many import libraries in the wild that does not have
".dll." in their name. The trouble spot is to tell ordinary static
libraries and import libraries (a special kind of static library)
apart.

> That sounds too simple to be true though, so what about testing for the
> property that the import library has a bunch of references to a dll matching:
> 
>   /^[^:]*\.dll:/
> 
> Where the static library has a bunch of references to object files matching:
> 
>   /^[^:]*\.(o|lo|obj):/
> 
> ??
> 
> Are either of those a step in the right direction?

Unfortunately, that's also too naive. Import libraries on Cygwin/MinGW
does not match that...

Here's output from a Cygwin import library:

---------------------8<---------------------
$ objdump -f tests/testsuite.dir/034/.libs/libhello.dll.a
In archive tests/testsuite.dir/034/.libs/libhello.dll.a:

d000004.o:     file format pe-i386
architecture: i386, flags 0x00000038:
HAS_DEBUG, HAS_SYMS, HAS_LOCALS
start address 0x00000000


d000000.o:     file format pe-i386
architecture: i386, flags 0x00000039:
HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS
start address 0x00000000


d000003.o:     file format pe-i386
architecture: i386, flags 0x00000039:
HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS
start address 0x00000000


d000002.o:     file format pe-i386
architecture: i386, flags 0x00000039:
HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS
start address 0x00000000


d000001.o:     file format pe-i386
architecture: i386, flags 0x00000039:
HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS
start address 0x00000000
---------------------8<---------------------

I'm noting that it does not have any pei-i386, so that idea
fell by the wayside.

Also, I had a look at the "dumpbin -symbols" output and don't
know how to pick out import symbols from it, so I'm not sure
if I can make func_win32_libid support that case. I guess one
could look for the presence of symbols with __IMPORT_DESCRIPTOR
in their name, but that seems a bit fragile...

Hmmm.

Cheers,
Peter