LADSoft
How to use Coff2IEEE
After looking at https://github.com/LADSoft/OrangeC/blob/master/doc/general/Coff2IEEE.md I've thought that I can use an import lib created by MSVC to convert it to OrangeC import libraries.
So I've taken the ones found at https://ci.appveyor.com/api/projects/GitMensch/gnucobol-3-x-vs/artifacts/dependencies-x86.7z?job=Image:%20Visual%20Studio%202019;%20Configuration:%20Release;%20Platform:%20x86 in lib directory, then did
$ coff2ieee -ozlib.l zlib.lib
coff2ieee (OrangeC) Version 6.0.50.236
Copyright (C) LADSoft 2006-2021
converting library file
failed
Where have I gone wrong?
Side notes:
- it seems there's a
\nmissing after failed, if I execute two commands like this in a row I get
Copyright (C) LADSoft 2006-2021
converting library file
failedcoff2ieee (OrangeC) Version 6.0.50.236
Copyright (C) LADSoft 2006-2021
converting library file
failed
- instead of "converting library file" an output of "converting library file zlib.lib" (maybe with full path) would be reasonable.
I think coff2ieee only works on actual COFF files, .lib are static libraries IIRC and a completely different format.
.lib are static libraries
Hm, do we both reference the lib files that tell cl.exe (actually link.exe) to resolve symbols by dll entry points (and the dll's being used at runtime)?
I did some checks of the actual .lib format btw: it seems to be an offset of COFF files itself, so it should be theoretically possible to have a program that unpacks the COFF files into a temp folder, then using a COFF->IEEE conversion, then running through everything.
i think coff2ieee may do this already... one thing I was thinking though is sometimes microsoft changes the format of COFF files... we've bin bit by that before... mileage may very with the latest VS runtimes...
I have just finished checking through COFF2IEEE, it should, in theory, actually be able to do the conversion, however there are some issues with the way the COFF2IEEE program works, namely the following:
-
Ignoring the longnames
This is an issue notably due to the fact that the longnames header is necessary for some of the longer names, as the Name being 16 bytes long is insufficient for this task
-
Ignoring the second linker member This is necessary to quickly go to each and every archive member header, in theory, if you memory mapped the file and parsed it in-memory, we could speed up conversion of .lib files to the IEEE format with multithreading if done judiciously, this is a different project alltogether however
These are important to look at in the future, however I think the priority if we want "better" parsing here would be the longnames member and just ignore the second linker member and relegate the multithread conversion idea to a different time.
I actually began work on making a new straight-up library for parsing the LIB and COFF files out so I'll probably just continue that work once I have the time to and add it in so that it's easier to read what's going on in coff2ieee
Work on the drop-in library looks good, I will probably throw up a new repo entirely for it as I plan on it being able to be used outside of any specific project, when that happens I'll throw a link here, and I'd like some feedback as I'll probably work on it for quite awhile as the COFF spec is a pretty hefty thing and parts of it are really, really poorly defined.
If you don't know of those yet you may want to have a look at https://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/mingw-w64-tools/ - at least genlib is COFF related.
My source has been a word document entitled pecoff_v8 atm, it's been good, though lacking a bit of documentation, and is literally the same thing as the official online microsoft documentation.
The first issue of getting parsing of static libraries is done, the secondary thing of getting PE files and DLLs parsed is whatever but will be worked on. The main thing I want out of a redesign is being able to utilize the 3rd linker member for accurate names.
Edit: my main sources are https://web.archive.org/web/20100314154747/http://www.microsoft.com/whdc/system/platform/firmware/PECOFF.mspx and https://docs.microsoft.com/en-us/windows/win32/debug/pe-format#archive-library-file-format
Update: got more than one file working (at least for the first three members, the easiest portion to actually parse and verify since dumpbin works on it...)
Archive member name at C2: //
6189E1CB time/date Mon Nov 8 21:49:47 2021
uid
gid
0 mode
25 size
correct header end
vs my tellg debug setup:
1
First: 1
92
Second: 1
189
Third: 1
The docs I'm 99% sure say we need to be aligned on a 1-bit boundary (n % 2 == whatever). All of this is done AFTER the alignment... if it's needed at all, that is.... Sometimes it demands alignment So location 1 happens at location 9, 189 is ??????? and sometimes this stuff happens whatever, as shown here:
9
First: 1
200414
Second: 1
397218
Third: 1
^ VS2022 Coff2Ieee.lib on my changes
And another example:
C:\OrangeC\static_library_parser>parselib.exe ..\src\lib\ms\dlpe.lib
9
First: 1
305001
Second: 0
/ 1636426187 0 301337 `
^ that indicates that we grabbed something 1 too early, meaning we needed to skip 1...
W H Y
bangs head against docs
Apparently tellg was lying to me about it's location somehow or I read things wrong... not particularly happy with how this is going now :/ Looks like a true cleaning house in my code will have to happen since I am abusing certain things in code...
I have further confirmed that tellg is ABSOLUTELY lying about it's location to me, being as far away as 5 characters in rudimentary testing... NOT happy to discover an issue in a standard library.... I need to investigate further for why this is happening and see if you guys are having this issue...
I actually figured out my issue: Turns out that when you're not in binary read mode funky stuff goes on in-code for no apparent reason whatsoever... Dunno why, but it does, probably has to do with CRLF -> LF conversion in line endings or something else funky happening....
I'll throw the code up probably later tonight so that you can judge what I've been doing so far, I THINK it's ok, but COFF parsing (rather than just parsing the lib) is currently not completely supported.
https://github.com/chuggafan/COFFParser Here's a link to what I have so far, I'm liable to forget that this project will exist, I do want as much info about how I've been doing things so far though, but I think for beginning a project like this it's OK, I've gotten the first 3 linker members to consistently be parsed along with all the info contained within...
yeah if not in binary mode on windows, CRs get stripped out before the program sees the data so you actually lose data. That is why the tellg was off too...