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

Puyan Lotfi via llvm-commits llvm-commits at lists.llvm.org
Thu Sep 6 20:17:10 PDT 2018


So with clang-6 I get:

Contents of section .zdebug_foo:
 0000 5a4c4942 00000000 00000008 789c6360  ZLIB........x.c`
 0010 80000000 080001                      .......
Contents of section .notdebug_foo:
 0000 00000000 00000000                    ........
Contents of section .rela.debug_foo:
 0000 01000000 00000000 0a000000 00000000  ................
 0010 00000000 00000000                    ........
Contents of section .symtab:
 0000 00000000 00000000 00000000 00000000  ................
 0010 00000000 00000000                    ........
Contents of section .strtab:
 0000 0000                                 ..
Contents of section .shstrtab:
 0000 002e7a64 65627567 5f666f6f 002e6e6f  ..zdebug_foo..no
 0010 74646562 75675f66 6f6f002e 72656c61  tdebug_foo..rela
 0020 2e646562 75675f66 6f6f002e 73687374  .debug_foo..shst
 0030 72746162 002e7374 72746162 002e7379  rtab..strtab..sy
 0040 6d746162 00                          mtab.


but as you noted, with clang-8 TOT (in the GNU Case) I get:

Contents of section .debug_foo:
 0000 00000000 00000000                    ........
Contents of section .zdebug_foo:
 0000 00000000 00000000 00000008 789c6360  ............x.c`
 0010 80000000 080001                      .......
Contents of section .notdebug_foo:
 0000 00000000 00000000                    ........
Contents of section .rela.debug_foo:
 0000 01000000 00000000 0a000000 00000000  ................
 0010 00000000 00000000                    ........
Contents of section .symtab:
 0000 00000000 00000000 00000000 00000000  ................
 0010 00000000 00000000                    ........
Contents of section .strtab:
 0000 0000                                 ..
Contents of section .shstrtab:
 0000 002e7a64 65627567 5f666f6f 002e6e6f  ..zdebug_foo..no
 0010 74646562 75675f66 6f6f002e 72656c61  tdebug_foo..rela
 0020 2e646562 75675f66 6f6f002e 73687374  .debug_foo..shst
 0030 72746162 002e7374 72746162 002e7379  rtab..strtab..sy
 0040 6d746162 00000000 00000000 00000000  mtab............

Something here does not look right. 


PL


Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On 6 September 2018 5:52 PM, Jordan Rupprecht via Phabricator via llvm-commits <llvm-commits at lists.llvm.org> wrote:

> rupprecht added a comment.
> 

> 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.
> 

> Repository:
> rL LLVM
> 

> https://reviews.llvm.org/D49678
> 

> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits

-------------- next part --------------
A non-text attachment was scrubbed...
Name: publickey - puyan at puyan.org - 0xD3F77200.asc
Type: application/pgp-keys
Size: 1749 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20180907/84d37c39/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 509 bytes
Desc: OpenPGP digital signature
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20180907/84d37c39/attachment.sig>


More information about the llvm-commits mailing list