[llvm] r229129 - llvm-pdbdump: Improve printing of functions and signatures.

[Zachary Turner]

It *might* work with an object file if you compile with /Z7
<https://msdn.microsoft.com/en-us/library/958x11bc.aspx>.  To be honest I
never even thought to check that because it's so rare (e.g. almost
non-existant) that anyone does that in practice.  It works with EXE files
too, but only to the extent that the EXE tells it how to find the PDB, and
then it opens the PDB and verifies the checksum matches.  It still ends up
hitting the PDB for the data.  So most tests (and definitely initial tests)
are probably going to be checking in strictly PDBs, no EXEs or obj files.

On Fri Feb 13 2015 at 10:55:19 AM David Blaikie <dblaikie at gmail.com> wrote:

> On Fri, Feb 13, 2015 at 10:52 AM, Zachary Turner <zturner at google.com>
> wrote:
>
>>
>>
>> On Fri Feb 13 2015 at 10:43:23 AM David Blaikie <dblaikie at gmail.com>
>> wrote:
>>
>>> On Fri, Feb 13, 2015 at 10:32 AM, Zachary Turner <zturner at google.com>
>>> wrote:
>>>
>>>> Good question.  I mentioned it in one of the very first commit
>>>> messages, but I guess that's been a while with many more commit messages
>>>> since then, so it's been lost.
>>>>
>>>> Basically, the dwarf tests are tests against llvm-dwarfdump.  So
>>>> without llvm-pdbdump, there can't be any tests.  I could iterate, as you
>>>> said, but right now llvm-pdbdump doesn't really support many command line
>>>> options or ways to specify what to dump.  It just dumps everything.  Which
>>>> is often very slow and pollutes the output, making it difficult to check
>>>> that only the thing you care about is the way you expect and also making
>>>> the test suite run slowly.  Also, it's not just that I'm iterating right
>>>> now, it's that some stuff just prints wrong, or doesn't print at all.
>>>>
>>>
>>> Slow? Usually the inputs (reduced test cases) are so small that we're
>>> dealing with a tiny amount of debug info. Are the APIs/COM stuff so
>>> abysmally slow as to be observable even on such small test cases?
>>>
>> I suppose the slowness issue would go away if I were dynamically linking
>> against the CRT.  So this actually probably isn't an issue now that I think
>> about it.  I've been statically linking in my tests so far, and you get a
>> ton of stuff in the file.
>>
>
> Oh, we don't link at all - just run against object files. Does the PDB
> format even work against object files? I guess it might not...
>
>
>>
>>
>>>
>>> Even if it's not finished, it's a great way to iteratively build up the
>>> test suite, avoid regressing one piece you fixed yesterday when you go to
>>> improve something else tomorrow, and saves going back at the end and trying
>>> to build up a comprehensive test suite - doing it iteratively seems easier
>>> & more likely to be thorough. (doing it at the end/after a lot of
>>> development it's hard to remember all the interesting corner cases you had
>>> to address along the way)
>>>
>>
>> I see where you're coming from.  The reason I've held off so far is just
>> that it was expected I would be changing the output with every patch.  So
>> it would have just created a lot of churn on the tests, where at any given
>> point, I wasn't actually testing that anything worked (because it was known
>> not to work), but rather just that it matched whatever the output at the
>> time was.  So it felt to me like I wasn't testing the desired behavior, but
>> just the current behavior, and I would have spent as much time fixing the
>> tests after each patch as on working on the patch itself.
>>
>> Either way, I've got one patch that's ready to upload, and another patch
>> I'm in the middle of.  Neither one is very big.  After that I'll get some
>> tests in.  Maybe even this afternoon.
>>
>
> Cool cool. Not sure how much experience you've had with FileCheck, but it
> does make it pretty easy not to be overly constrained if there are bits of
> bad output you don't care about yet & the cost of updating the tests is
> fairly low usually (format choices can be a deciding factor here - some
> formats are easier to check & more resilient to change than others - and
> some ways of writing the check lines are more resilient than others too).
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150213/99330c56/attachment.html>