[PATCH] D49678: [llvm-objcopy] Adding support for compressed DWARF debug sections.

[Puyan Lotfi via Phabricator via llvm-commits]

plotfi added a comment.

In https://reviews.llvm.org/D49678#1226825, @rupprecht wrote:

> In https://reviews.llvm.org/D49678#1226534, @plotfi wrote:
>
> > In https://reviews.llvm.org/D49678#1222836, @chandlerc wrote:
> >
> > > Reverted temporarily in r341360 to unbreak my build and the aarch64 build bot. Let me know if I can help with the investigation in any way.
> >
> >
> > @jakehehrlich @chandlerc I need help reproing this. I finally got an aarch64 setup up and running and the tests pass. I don't understand why this would fail.
>
>
> Looks like I'm able to repro this on my machine. (I hit it while I was running my own objcopy tests and happened to be synced to when this was recommitted). I can work with you on this.
>
> I'm wrapping up for the day so I don't have time to go much further, but one thing I did notice that was really funny is there are multiple sections with the same name, e.g. for compress-debug-sections-zlib.test.tmp-compressed.o:
>
>   Section {
>     Index: 1
>     Name: .debug_foo (20)
>     Type: SHT_PROGBITS (0x1)
>     Flags [ (0x0)
>     ]
>     Address: 0x0
>     Offset: 0x40
>     Size: 8
>     Link: 0
>     Info: 0
>     AddressAlignment: 0
>     EntrySize: 0
>   }
>   Section {
>     Index: 2
>     Name: .debug_foo (20)
>     Type: SHT_PROGBITS (0x1)
>     Flags [ (0x800)
>       SHF_COMPRESSED (0x800)
>     ]
>     Address: 0x0
>     Offset: 0x48
>     Size: 35
>     Link: 0
>     Info: 0
>     AddressAlignment: 8
>     EntrySize: 0
>   }
>   
>   
>
> In other words, the FileCheck test that .debug_foo has the SHF_COMPRESSED flag is matching the wrong one. (Of course, it's not FileCheck that's wrong, it's the fact that there are somehow two sections with the same name).
>
> I don't think there's anything unique about my machine setup... it's just a regular x86-64 linux machine, cmake is configured to use a near-head clang to build things... I hope to have time to take a closer look at this tomorrow.


So, problem seems to be any usage of ArrayRef like this:

  ArrayRef<uint8_t> Magic = {'Z', 'L', 'I', 'B'};

So where I did:

  ArrayRef<uint8_t> Magic = {'Z', 'L', 'I', 'B'};
  std::copy(Magic.begin(), Magic.end(), Buf);

or:

ArrayRef<uint8_t> GnuPrefix = {'Z', 'L', 'I', 'B'};

  return StringRef(Section.Name).startswith(".zdebug") ||
         (Section.OriginalData.size() > strlen("ZLIB") &&
          std::equal(GnuPrefix.begin(), GnuPrefix.end(),
                     Section.OriginalData.data())) ||
         (Section.Flags & ELF::SHF_COMPRESSED);

clang8 would misbehave and I think this was improper usage of ArrayRef in the first place.
I'm surprised ubsan did not catch this.


Repository:
  rL LLVM

https://reviews.llvm.org/D49678