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

[Zachary Turner]

As long as you can get it to not do dead code detection (since not calling
any external code means it will probably figure out that your program
essentially does nothing) you can probably get away with not linking
against MSVCRT.  But linking dynamically against MSVCRT should reduce the
symbol pollution to the point that it's negligible.

On Fri Feb 13 2015 at 11:01:38 AM David Blaikie <dblaikie at gmail.com> wrote:

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