[llvm-bugs] [Bug 41499] New: [PATCH] llvm-pdbutil explain command fails due to unsigned long parser not existing

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=41499

            Bug ID: 41499
           Summary: [PATCH] llvm-pdbutil explain command fails due to
                    unsigned long parser not existing
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: DebugInfo
          Assignee: unassignedbugs at nondot.org
          Reporter: mike.auty at gmail.com
                CC: jdevlieghere at apple.com, keith.walker at arm.com,
                    llvm-bugs at lists.llvm.org,
                    paul_robinson at playstation.sony.com

Created attachment 21773
  --> https://bugs.llvm.org/attachment.cgi?id=21773&action=edit
Patch to add unsigned long parser template for llvm-pdbutil explain

Hiya,

Attempting to use llvm-pdbutil explain failed with:


$ llvm-pdbutil explain -offset 0x0 some.pdb
llvm-pdbutil: for the -offset option: Cannot find option named '0x0'!


I also noticed that other items which take a value have an = symbol after them
in the help, but not so for offset.  I checked the code and couldn't see why it
wouldn't work and a near-identical list of uints (such as dump-id for another
section) would work.  Then I realized that all the other lists were uint32_t,
but that explain's offsets were uint64_t.  I believe explain is the only place
this occurs which is why I filed it under here.

I looked for a uint64_t parser, but could only find an unsigned long long
parser, and an unsigned long parser.  Some more digging revealed that compilers
on x64 do not convert uint64_t to unsigned long long on those platforms, but to
unsigned long.  I added an unsigned long parser (patch attached) and the
explain parser started giving me the expected output:


Explaining file offset 0 of file '/path/to/some.pdb'.
Block:Offset = 0:0000.
Address is in block 0 (allocated).
  This corresponds to offset 0 of the MSF super block, 
  which is part of the MSF file magic.


I don't know if that's the best way of resolving the issue, or if it should be
filed under a different component.  It could be that the parser template should
actually be uint64_t rather than unsigned long long, but I didn't want to
disrupt anything that currently worked (and my C++ is rudimentary at best), so
I just added the unsigned long parser in addition to the existing one.  Let me
know if there's any additional information required...  5:)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20190415/aa6bc4b9/attachment.html>