[PATCH] Add a few basic tests for llvm-pdbdump

[David Blaikie]

On Fri, Feb 20, 2015 at 12:51 PM, Zachary Turner <zturner at google.com> wrote:

> RVA - relative virtual address (i.e. offset from the beginning of the
> module, so that when it is loaded at runtime, you add that value to the
> module load address to get the absolute virtual address of the symbol).  I
> thought this was a universal term, but I guess not :)  What does DWARF call
> this?
>

DWARF actually uses runtime relocations - so it's a relocatable address
(like those found in the actual executable data - jump destinations, etc).
Usually that means when you dump the dwarf & the dumper prints the bytes of
the 'address', it's printing whatever bytes are kept there to process the
relocation (which, in an object file is sometimes zeros - because it's an
unresolved symbol that has to wait until link time - and in a linked
executable it'd be the relative virtual address you're describing (because
the relocation says "take what's in these bytes, add the base address, and
write that over the bytes" - other executable formats could have
relocations that store the bytes off in the relocation table rather than in
the bytes to be modified, etc) - but I'm not sure what, if anything, the
canonical term is for that in the ELFine world)


>
> On Fri Feb 20 2015 at 12:48:50 PM David Blaikie <dblaikie at gmail.com>
> wrote:
>
>> On Fri, Feb 20, 2015 at 12:44 PM, Zachary Turner <zturner at google.com>
>> wrote:
>>
>>> Bump.  The options being specified on the command line might be a little
>>> confusing.  I actually have a followup patch which drastically simplifies
>>> the options and probably will make reading these tests easier.  But I was
>>> goign to commit that after this (as the patch updates the tests and output
>>> as well).
>>>
>>
>> Sure
>>
>>
>>> In any case, the basic idea of pdbdump-symbol-format.test is to dump
>>> symbol entries from object files.  Since we don't know what the internal
>>> format of PDB is, I wrote the dumper to dump entries in ways that would
>>> make it easier for people to understand what the information in the PDB
>>> represents *semantically*, as opposed to physically.  This is useful for
>>> someone writing a debugger, for example, so that they can know at a high
>>> level what kind of information they can expect to get from the PDB.
>>>
>>
>> *nod* There's some risk that a higher level output might hide
>> representational details that are relevant to consuming the debug info -
>> hence the desire to keep it pretty bare-metal. But there's certainly
>> tradeoffs - dwarfdump is growing higher level dumping functionality slowly
>> at the moment, so the two tools might end up meeting in the middle, as it
>> were.
>>
>>
>>> In this example, you can see that the PDB knows about 2 object files,
>>> symbolformat.obj and symbolformat-fpo.obj.  For each one, all the symbols
>>> are dumped, which consist mostly of functions due to the fact that the
>>> original source code also consists mostly of functions.  RVAs
>>
>>
>> RVAs?
>>
>> Anyway, looks like a good start - no doubt we'll iterate on it all a lot
>> as it goes along.
>>
>>
>> - David
>>
>>
>>
>>> of the functions are dumped as well, in a format like
>>> [start+prologue_length - end-epilogue_length]
>>>
>>>
>>> http://reviews.llvm.org/D7656
>>>
>>> EMAIL PREFERENCES
>>>   http://reviews.llvm.org/settings/panel/emailpreferences/
>>>
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150220/e50291b5/attachment.html>