[llvm] r310262 - [DebugInfo][DWARF] Correct some usages of PRIx32 to PRIx64

[David Blaikie via llvm-commits]

On Mon, Aug 7, 2017 at 12:43 PM Simon Dardis <Simon.Dardis at imgtec.com>
wrote:

>
> > From: David Blaikie [dblaikie at gmail.com]
> > Sent: 07 August 2017 19:57
> > To: Simon Dardis; llvm-commits at lists.llvm.org
> > Subject: Re: [llvm] r310262 - [DebugInfo][DWARF] Correct some usages of
> PRIx32 to PRIx64
>
> Sorry, I misread the buildbot's current set of changes, build 4915 should
> show that it passes.
>
> > Was it only failing on MIPS?
>
> As far as I could see it was only failing on MIPS, it has been on my
> to-fix list for some time as I
> believed it was a libc bug which required upgrading the machines. If it
> had been failing on other
> machines, I believe clayborg or someone else would have spotted it and
> reverted it.
>
> > Is it possible to test it more portably?
>
> Honestly, I'm not sure. The failing unittests synthesize an object section
> with dwarf debug info
> then verify it and match the textual output of the verifier against known
> correct textual output. I
> believe the existing tests are sufficient.
>
> Providing input to llc with debug info and getting llvm-dwarfdump to
> verify the input seems to
> be exactly the equivalent what the unit test is doing.
>

Another option (mentioned in the branch of this thread with Paul Robinson)
is to have assembly or object files checked in (or there is some support
for generating DWARF from yaml files - not sure if it's sufficiently
descriptively powerful for this issue) - this may be necessary when testing
DWARF that LLVM doesn't currently produce but for which the DWARF parsing
APIs are intended to support, which seems to be the case here.

Getting an object file or crafting one (taking a simple example from clang,
for example & tweaking some properties) might be enough to test this.
Though of course coming up with a very large offset could be tricky - maybe
an assembly test would work well by making it easy to write a large region
of zeros or whatever (I don't know assembly too well, but I'm guessing
there's a directive that's like "a million bytes of zero") to create
interesting offsets if they have to actually be real (if they don't have to
be real offsets - the file can just contain lies, large offsets into a
section that's actually much smaller, etc).


> The only other thing I can think of is dropping the use of format(..)
> completely and using formatv(..)
> which claims to support type-safe / compile time checked formatting.
>

Might be a better fix, but hopefully orthogonal to the discussion of how to
test that the issue is fixed.

- Dave


>
> If you have any suggestions, I'm quite open to them.
>
> Thanks,
> Simon
>
> > On Mon, Aug 7, 2017 at 11:51 AM Simon Dardis <Simon.Dardis at imgtec.com>
> wrote:
>
> >> From: David Blaikie [dblaikie at gmail.com]
> >> Sent: 07 August 2017 19:34
> >> To: Simon Dardis; llvm-commits at lists.llvm.org
> >>  Subject: Re: [llvm] r310262 - [DebugInfo][DWARF] Correct some usages
> of PRIx32 to PRIx64
> > > Test case?
>
> > This is already covered by:
> > LLVM-Unit::DWARFDebugInfo.TestDwarfVerifyInvalidCURef
> > LLVM-Unit::DWARFDebugInfo.TestDwarfVerifyInvalidStmtList
>
> > Which have been failing for some time on clang-cmake-mips(el):
>
> > http://lab.llvm.org:8011/builders/clang-cmake-mips/builds/4913
>
> > build 4914 when it's finished, should show those tests passing.
>
> > Thanks,
>
> > SImon
>
>
>
>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170807/3bd09c88/attachment.html>