Re: [PATCH] Add pdb archive target

[Mark Harmstone <mark@harmstone.com>]

On 12/8/22 07:14, Jan Beulich wrote:
 > On 12.08.2022 01:26, Mark Harmstone wrote:
 >> On 11/8/22 14:02, Jan Beulich wrote:
 >>  > On 26.07.2022 01:44, Mark Harmstone wrote:
 >>  >> This adds support for the "Multi-Stream Format" container format that
 >>  >> MSVC uses for its PDB debugging files, as documented at
 >>  >> https://llvm.org/docs/PDB/MsfFile.html.
 >>  >
 >>  > Looking at binutils/testsuite/binutils-all/pdb*.d I wonder what "support"
 >>  > here means: What is dumped is the binary contents of the file (claimed
 >>  > to be coming from section .data) rather than the inner file structure.
 >>
 >> I'm not quite sure what you're getting at. This is purely for PDB files as
 >> archives, there is no inner file structure. The tests check that the hex
 >> dump of the files matches one possible way to represent an archive of the
 >> dummy files.
 >
 > If it's an archive (and hence can hold multiple files), then surely it
 > has an internal structure. Or else your patch also wouldn't be needed,
 > btw. Dumping a *.a file gives you an idea what's in the file. I would
 > have expected the same for *.pdb (to a reasonable extent at least).
 > One might then easily see number of members, block size, etc. Perhaps
 > even the sizes of the individual members.

Right, I see what you mean - so that "objdump -x" gives you something
interesting...

 >>  > Is there a reason for this 4-or-more digits naming of the file? Would
 >>  > it make sense to use 8 digits (beyond which the index apparently
 >>  > cannot grow)?
 >>
 >> In practice, 4 digits is plenty. The number of files in the archive is
 >> proportional to the number of object files linked into the image... for the
 >> NT kernel, which is probably the most complicated EXE out there, the PDB
 >> has 1,100 files. I can't imagine anybody will ever go over 65,535 - and it's
 >> not visible anyway, unless you play around with ar.
 >
 > Since you know the number of files in the archive, may I suggest that you
 > base the number of digits on that number of members, such that all
 > elements would be extracted to files with names of identical length?

Yep, good idea.

Thanks for your help Jan - I'll submit another patch incorporating your
suggestions shortly.

Mark