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

[David Blaikie]

On Fri, Feb 13, 2015 at 10:59 AM, Zachary Turner <zturner at google.com> wrote:

> 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.
>

*nod* makes sense - and yeah, dynamic linking (do you need to link anything
if you just make a dll out of a single .obj file that doesn't call any
external code (I guess that still requires MSVCRT dynamically or
statically?)?).


>
> 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/5d5df70e/attachment.html>