Re: [chromium-dev] Linux stack trace line numbers + .debug_aranges

19 views
Skip to first unread message

Takuto Ikuta

unread,
Jul 1, 2021, 7:53:17 PM7/1/21
to Albert Wong, Clang maintainers, Chromium-dev

On Fri, Jul 2, 2021 at 5:01 AM Albert J. Wong (王重傑) <ajw...@chromium.org> wrote:
Hi folks,

I've been making progress on adding line-numbers into the stack traces in linux.

I've gotten it mostly working, but it's a bit slow. I wanted to explore using the DWARF .debug_aranges table to speed up processing of the line numbers, however, it seems that LLVM does NOT output this by default.

Does anyone know much about this table?  In particular, I had 2 questions:
  (1) Would people object if I added -gdwarf-aranges into all the cflags? We likely need to measure the build artifact size implication...

I think we want to take care build/link speed too especially on CQ.
 
  (2) Does anyone know if .debug_aranges is guaranteed to be sorted?

The DWARF-4 spec does NOT seem to guarantee the range is sorted (whyyyyyy?) but maybe we can know that llvm will enforce this? It'd allow me to binary search the table.

-Albert

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CALcbsXDMH3%3D8QV7fuiBYLEYqV4xoGbinH9RL-hVu01GRYjWvbg%40mail.gmail.com.

Erik Chen

unread,
Jul 1, 2021, 8:01:40 PM7/1/21
to Takuto Ikuta, gat...@chromium.org, Albert Wong, Clang maintainers, Chromium-dev
+Gary Tong as this may affect CQ.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CALNjmMozbq%3DZZXZuL3w1nyd1aopf92RdRTT83U2vD_GV0ZLfig%40mail.gmail.com.

Fergal Daly

unread,
Jul 4, 2021, 11:34:25 PM7/4/21
to erik...@chromium.org, Takuto Ikuta, gat...@chromium.org, Albert Wong, Clang maintainers, Chromium-dev
If this doesn't work, can we just set

print_unsymbolized_stack_traces = true

and pipe all CQ test runs through `tools/valgrind/asan/asan_symbolize.py`? This is what I do for all my linux builds currently,

F

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAEYHnr0x_UfHqHrq8R2sNc4nXGD_ii%3DQ8ZbYkznDfQQBgAm2rw%40mail.gmail.com.

Philip Pfaffe

unread,
Jul 13, 2021, 6:23:04 AM7/13/21
to Chromium-dev, Fergal Daly, Takuto Ikuta, Gary Tong, Albert J. Wong, Clang maintainers, Chromium-dev, erik...@chromium.org

Even if the ranges were sorted, I'm not sure a binary search would work. .debug_aranges is segmented by compilation unit into sets of ranges. Sets are variable length and start with a header that identifies the compilation unit, which I think won't allow for random access. You might have to build your own lookup data structure.

Cheers,
Philip

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev+unsubscribe@chromium.org.

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CALNjmMozbq%3DZZXZuL3w1nyd1aopf92RdRTT83U2vD_GV0ZLfig%40mail.gmail.com.

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev+unsubscribe@chromium.org.

Albert J. Wong (王重傑)

unread,
Jul 13, 2021, 5:16:56 PM7/13/21
to Philip Pfaffe, Chromium-dev, Fergal Daly, Takuto Ikuta, Gary Tong, Clang maintainers, erik...@chromium.org

On Tue, Jul 13, 2021 at 3:23 AM Philip Pfaffe <pfa...@chromium.org> wrote:

Even if the ranges were sorted, I'm not sure a binary search would work. .debug_aranges is segmented by compilation unit into sets of ranges. Sets are variable length and start with a header that identifies the compilation unit, which I think won't allow for random access. You might have to build your own lookup data structure.

True, but I was hoping to at least binary search within each set of ranges.  After reading the range header, you know the length of the size and can binary search from there. Also, I noticed looking at the dwarfdump on libbase.so that, for some reason, clang is generating a bunch of small ranges starting at address 0 within one set...which doesn't seem super useful?  If searching, it allows you to have multiple matches since the ranges overlap. Not sure what to make of that.

That being said, in the current version of the code with a full linear search, it's not sooo slow.  The current hiccup is, apparently, adding .dwarf_aranges causes the TSAN output to _remove_ the absolute path from the "SUMMARY:" line so you get


SUMMARY: ThreadSanitizer: data race tools_sanity_unittest.cc in base::(anonymous namespace)::TOOLS_SANITY_TEST_CONCURRENT_THREAD::ThreadMain()instead ofSUMMARY: ThreadSanitizer: data race base/tools_sanity_unittest.cc:249:13 in base::(anonymous namespace)::TOOLS_SANITY_TEST_CONCURRENT_THREAD::ThreadMain()

which of course breaks our expectations regexps.  I haven't figure out where this line is printed from so I can't inspect the code...but it seems like there might be a bug in the symbolization code if *adding* .dwarf_aranges causes us to NOT have line number info.

But if we can sort this out, I think we can at least have line-numbers on local stack traces pretty quickly.

-Albert
 

Cheers,
Philip

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

Brett Wilson

unread,
Jul 13, 2021, 5:52:01 PM7/13/21
to ajw...@chromium.org, Philip Pfaffe, Chromium-dev, Fergal Daly, Takuto Ikuta, Gary Tong, Clang maintainers, erik...@chromium.org
On Tue, Jul 13, 2021 at 2:18 PM Albert J. Wong (王重傑) <ajw...@chromium.org> wrote:

On Tue, Jul 13, 2021 at 3:23 AM Philip Pfaffe <pfa...@chromium.org> wrote:

Even if the ranges were sorted, I'm not sure a binary search would work. .debug_aranges is segmented by compilation unit into sets of ranges. Sets are variable length and start with a header that identifies the compilation unit, which I think won't allow for random access. You might have to build your own lookup data structure.

True, but I was hoping to at least binary search within each set of ranges.  After reading the range header, you know the length of the size and can binary search from there. Also, I noticed looking at the dwarfdump on libbase.so that, for some reason, clang is generating a bunch of small ranges starting at address 0 within one set...which doesn't seem super useful?  If searching, it allows you to have multiple matches since the ranges overlap. Not sure what to make of that.

Ranges that start at 0 were dead-code eliminated by the linker. I think it would slow the linker down too much to have to rewrite all of the ranges when it removes one, so it just marks that range as invalid.

Brett

Brett Wilson

unread,
Jul 13, 2021, 5:54:38 PM7/13/21
to ajw...@chromium.org, Philip Pfaffe, Chromium-dev, Fergal Daly, Takuto Ikuta, Gary Tong, Clang maintainers, erik...@chromium.org
Also: the sequences tend to be sorted, but aren't always. Here's the Fuchsia debugger code for this (it uses LLVM to do some low-level stuff):

Brett 
Reply all
Reply to author
Forward
0 new messages