Thanks Sri.
I've sent out
https://reviews.llvm.org/D94063 and https://reviews.llvm.org/D94064 for
review, which include fixes for the lldb+ranges-on-subprograms issues I
could find so far.
On Wed, Dec 30, 2020 at 6:53 PM Sriraman Tallam wrote:
>
>
> On Tue, Dec 29, 2020 at 4:44 PM Sriraman Tallam
> wrote:
>
>>
>>
>> On Tue, Dec 29, 2020 at 2:06 PM David Blaikie wrote:
>>
>>>
>>>
>>> On Wed, Dec 23, 2020 at 7:02 PM Sriraman Tallam
>>> wrote:
>>>
On Wed, Dec 23, 2020 at 4:46 PM David Blaikie
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.
>>>
>>> I'd looked at the DWARF being well-formed & for the most part efficient
>>> as it can be, given the nature of Basic Block Sections - but I haven't done
>>> any debugger testing with it.
>>>
>>> You mentioned gdb might already be pretty well setup for functions that
>>> are split into multiple chunks because GCC does this under some
>>> circumstances?
>>>
>>> But it looks like lldb might not be so well situated.
>>>
>>>
How do I test if this breaks with bbsections?
>>>
>>> Test printing out the value of a variable in a function with more than
>>> one section, eg:
>>>
>>> $ ~/dev/llvm/build/default/bin/lldb ./b
>>>
>>> (lldb) target create "./b"
>>>
>>> Current executable set to '/usr/local/google/home/blaikie/dev/scratch/b'
>>> (x86_64).
>>>
>>> (lldb) b main
>>>
>>> Breakpoint 1: where = b`main + 15, address = 0x0040112f
>>>
>>> (lldb) start
>>>
>>> *error: *'start' is not a valid command.
>>>
>>> (lldb) r
>>>
>>> Process 1827628 launched: '/usr/local/google/home/blaikie/dev/scratch/b'
>>> (x86_64)
>>>
>>> Process 1827628 stopped
>>>
>>> * thread #1, name = 'b', stop reason = breakpoint 1.1
>>>
>>> frame #0: 0x0040112f b`main at test.cpp:5:7
>>>
>>>2 int j = 12;
>>>
>>>3}
>>>
>>>4int main() {
>>>
>>> -> 5 int i = 7;
>>>
>>>6 if (i)
>>>
>>>7f1();
>>>
>>>8}
>>>
>>> (lldb) p i
>>>
>>> error: :1:1: use of undeclared identifier 'i'
>>>
>>> i
>>>
>>> ^
>>>
>>> (lldb) ^D
>>>
>>> $ clang++-tot test.cpp -g -o b
>>>
>>> $ ~/dev/llvm/build/default/bin/lldb ./b
>>>
>>> (lldb) target create "./b"
>>>
>>> Current executable set to '/usr/local/google/home/blaikie/dev/scratch/b'
>>> (x86_64).
>>>
>>> (lldb) b main
>>>
>>> Breakpoint 1: where = b`main + 15 at test.cpp:5:7, address =
>>> 0x0040112f
>>>
>>> (lldb) r
>>>
>>> Process 1828108 launched: '/usr/local/google/home/blaikie/dev/scratch/b'
>>> (x86_64)
>>>
>>> p i
>>>
>>> Process 1828108 stopped
>>>
>>> * thread #1, name = 'b', stop reason = breakpoint 1.1
>>>
>>> frame #0: 0x0040112f b`main at test.cpp:5:7
>>>
>>>2 int j = 12;
>>>
>>>3}
>>>
>>>4int main() {
>>>
>>> -> 5 int i = 7;
>>>
>>>6 if (i)
>>>
>>>7f1();
>>>
>>>8}
>>>
>>> (lldb) p i
>>>
>>> (int) $0 = 0
>>>
>>> (lldb) ^D
>>>
>>> $ cat test.cpp
>>>
>>> void f1() {
>>>
>>> int j = 12;
>>>
>>> }
>>>
>>> int main() {
>>>
>>> int i = 7;
>>>
>>> if (i)
>>>
>>> f1();
>>>
>>> }
>>>
>>> So, yeah, seems like DW_AT_ranges on a DW_TAG_subprogram is a bit buggy
>>> with lldb & that'll need to be fixed for Propeller to be usable with lldb.
>>> For my "ranges everywhere" feature - nice to fix, but given we/Google/my
>>> use case uses -ffunction-sections, subprogram ranges don't actually ever
>>> get used in that situation (since every function starts at a new relocated
>>> address - subprogram address ranges can't share address pool entries anyway
>>> - so t
