llvm dev - Dec 2020 - lldb subprogram ranges support

Hey folks,

So I've been doing some more testing/implementation work on various address
pool reduction strategies previously discussed back in January (
http://lists.llvm.org/pipermail/llvm-dev/2020-January/thread.html#138029 ).

I've committed a -mllvm flag to allow experimenting with the first of these
strategies: Always using ranges in DWARFv5 (the flag has no effect pre-v5).
Since ranges can use address pool entries, this allows significant address
reuse (clang opt split-dwarf 13% reduction in object file size,
specifically a reduction in aggregate .rela.debug_addr size from 78MB to
16MB - the lowest this could go is approximately 8MB (this is the size of
.rela.debug_line)).

It causes one lldb test to
fail lldb/test/SymbolFile/DWARF/Output/debug-types-expressions.test which
reveals that lldb has some trouble with ranges on DW_TAG_subprograms.

Anyone happen to have ideas about what the problem might be? Anyone
interested in fixing this? (Jordan, maybe?)

Sri: Sounded like you folks had done some testing of Propeller with lldb -
and I'd expect it to trip over this same problem, since it'll cause
ranges
to be used for DW_TAG_subprograms to an even greater degree. Have you come
across anything like this?

Here's a small example:

(the test has an inline function to force the output file to have more than
one section (otherwise it'll all be in the text section, the CU's low_pc
will be relocatable and all the other addresses will be relative to that -
so there won't be any benefit to using ranges) and 'main' is the
second
function, so it starts at an offset relative to the address in the address
pool (which will be f2's starting address) and benefit from using ranges to
share that address)

$ cat test.cpp

inline __attribute__((noinline)) void f1() { }

void f2() {

}

int main() {

  int i = 7;

  f1();

}
$ ~/dev/llvm/build/default/bin/lldb ./a

(lldb) target create "./a"

Current executable set to
'/usr/local/google/home/blaikie/dev/scratch/always_ranges/a' (x86_64).

(lldb) b main

Breakpoint 1: where = a`main + 8 at test.cpp:5:7, address 0x0000000000401128

(lldb) r

Process 2271305 launched:
'/usr/local/google/home/blaikie/dev/scratch/always_ranges/a' (x86_64)

p iProcess 2271305 stopped

* thread #1, name = 'a', stop reason = breakpoint 1.1

    frame #0: 0x0000000000401128 a`main at test.cpp:5:7

   2    void f2() {

   3    }

   4    int main() {

-> 5      int i = 7;

   6      f1();

   7    }

(lldb) p i

(int) $0 = 0

$ ~/dev/llvm/build/default/bin/lldb ./b

(lldb) target create "./b"

Current executable set to
'/usr/local/google/home/blaikie/dev/scratch/always_ranges/b' (x86_64).

(lldb) b main

Breakpoint 1: where = b`main + 8, address = 0x0000000000401128

(lldb) r

Process 2271759 launched:
'/usr/local/google/home/blaikie/dev/scratch/always_ranges/b' (x86_64)

Process 2271759 stopped

* thread #1, name = 'b', stop reason = breakpoint 1.1

    frame #0: 0x0000000000401128 b`main at test.cpp:5:7

   2    void f2() {

   3    }

   4    int main() {

-> 5      int i = 7;

   6      f1();

   7    }

(lldb) p i

error: <user expression 0>:1:1: use of undeclared identifier 'i'

i

^

$ diff <(llvm-dwarfdump-tot a | sed -e "s/0x[0-9a-f]\{8\}//g")
<(llvm-dwarfdump-tot b | sed -e "s/0x[0-9a-f]\{8\}//g")

1c1

< a:    file format elf64-x86-64

---
> b:    file format elf64-x86-64
14c14

<               DW_AT_ranges    (indexed (0x0) rangelist 
---
>               DW_AT_ranges    (indexed (0x1) rangelist 
31,32c31,32

<                 DW_AT_low_pc  (00401120)

<                 DW_AT_high_pc (0040113c)

---
>                 DW_AT_ranges  (indexed (0x0) rangelist 
>                    [00401120, 0040113c))
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20201223/1e1cb9de/attachment.html>

On Wed, Dec 23, 2020 at 4:46 PM David Blaikie <dblaikie at gmail.com>
wrote:
> Hey folks,
>
> So I've been doing some more testing/implementation work on various
> address pool reduction strategies previously discussed back in January (
> http://lists.llvm.org/pipermail/llvm-dev/2020-January/thread.html#138029
> ).
>
> I've committed a -mllvm flag to allow experimenting with the first of
> these strategies: Always using ranges in DWARFv5 (the flag has no effect
> pre-v5). Since ranges can use address pool entries, this allows significant
> address reuse (clang opt split-dwarf 13% reduction in object file size,
> specifically a reduction in aggregate .rela.debug_addr size from 78MB to
> 16MB - the lowest this could go is approximately 8MB (this is the size of
> .rela.debug_line)).
>
> It causes one lldb test to
> fail lldb/test/SymbolFile/DWARF/Output/debug-types-expressions.test which
> reveals that lldb has some trouble with ranges on DW_TAG_subprograms.
>
> Anyone happen to have ideas about what the problem might be? Anyone
> interested in fixing this? (Jordan, maybe?)
>
> Sri: Sounded like you folks had done some testing of Propeller with lldb -
> and I'd expect it to trip over this same problem, since it'll cause
ranges
> to be used for DW_TAG_subprograms to an even greater degree. Have you come
> across anything like this?
>
Not sure David.  I think you tested basic block sections for v5 a while
back.  How do I test if this breaks with bbsections? I can give you a
simple program with bb sections that would create a lot of ranges. Any
pointers? My understanding of DWARF v5 is near zero so please bear with me.
Thanks.

>
> Here's a small example:
>
> (the test has an inline function to force the output file to have more
> than one section (otherwise it'll all be in the text section, the
CU's
> low_pc will be relocatable and all the other addresses will be relative to
> that - so there won't be any benefit to using ranges) and
'main' is the
> second function, so it starts at an offset relative to the address in the
> address pool (which will be f2's starting address) and benefit from
using
> ranges to share that address)
>
> $ cat test.cpp
>
> inline __attribute__((noinline)) void f1() { }
>
> void f2() {
>
> }
>
> int main() {
>
>   int i = 7;
>
>   f1();
>
> }
> $ ~/dev/llvm/build/default/bin/lldb ./a
>
> (lldb) target create "./a"
>
> Current executable set to
> '/usr/local/google/home/blaikie/dev/scratch/always_ranges/a'
(x86_64).
>
> (lldb) b main
>
> Breakpoint 1: where = a`main + 8 at test.cpp:5:7, address >
0x0000000000401128
>
> (lldb) r
>
> Process 2271305 launched:
> '/usr/local/google/home/blaikie/dev/scratch/always_ranges/a'
(x86_64)
>
> p iProcess 2271305 stopped
>
> * thread #1, name = 'a', stop reason = breakpoint 1.1
>
>     frame #0: 0x0000000000401128 a`main at test.cpp:5:7
>
>    2    void f2() {
>
>    3    }
>
>    4    int main() {
>
> -> 5      int i = 7;
>
>    6      f1();
>
>    7    }
>
> (lldb) p i
>
> (int) $0 = 0
>
> $ ~/dev/llvm/build/default/bin/lldb ./b
>
> (lldb) target create "./b"
>
> Current executable set to
> '/usr/local/google/home/blaikie/dev/scratch/always_ranges/b'
(x86_64).
>
> (lldb) b main
>
> Breakpoint 1: where = b`main + 8, address = 0x0000000000401128
>
> (lldb) r
>
> Process 2271759 launched:
> '/usr/local/google/home/blaikie/dev/scratch/always_ranges/b'
(x86_64)
>
> Process 2271759 stopped
>
> * thread #1, name = 'b', stop reason = breakpoint 1.1
>
>     frame #0: 0x0000000000401128 b`main at test.cpp:5:7
>
>    2    void f2() {
>
>    3    }
>
>    4    int main() {
>
> -> 5      int i = 7;
>
>    6      f1();
>
>    7    }
>
> (lldb) p i
>
> error: <user expression 0>:1:1: use of undeclared identifier
'i'
>
> i
>
> ^
>
> $ diff <(llvm-dwarfdump-tot a | sed -e "s/0x[0-9a-f]\{8\}//g")
> <(llvm-dwarfdump-tot b | sed -e "s/0x[0-9a-f]\{8\}//g")
>
> 1c1
>
> < a:    file format elf64-x86-64
>
> ---
>
> > b:    file format elf64-x86-64
>
> 14c14
>
> <               DW_AT_ranges    (indexed (0x0) rangelist >
> ---
>
> >               DW_AT_ranges    (indexed (0x1) rangelist >
> 31,32c31,32
>
> <                 DW_AT_low_pc  (00401120)
>
> <                 DW_AT_high_pc (0040113c)
>
> ---
>
> >                 DW_AT_ranges  (indexed (0x0) rangelist >
> >                    [00401120, 0040113c))
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20201223/f5522851/attachment.html>