Added ranges to Addr2line

[tig_freebsdfoundation.org]

Summary

Applied a patch that adds ranges support when the addresses of a CU is several discontinuous blocks.
Link to PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217736
Link to previous patch: https://sourceforge.net/p/elftoolchain/tickets/545/#6d97

Test Plan

Tested against 10000 random addresses in the .so file provided by the patch contributor. Output is the same as GNU addr2line.

[emaste]

Can you add a link to the PR/patch submission in here?

[markj]

contrib/elftoolchain/addr2line/addr2line.c

433

Indentation should be by four spaces.

441

The indentation here looks wrong.

502

This duplicates the block above, please try to merge them.

[markj]

In your testing, did you try passing -f or -i?

I have one general comment. I'm not a big fan of curlopc, I think it makes the code rather confusing. It's an optimization for the sorted case, but I'm not sure how much it actually helps. Can you provide some quick benchmark numbers to justify it? I also note that if the input is reverse-sorted, i.e., high addresses come first, then the curlopc optimization could make things slightly worse.

contrib/elftoolchain/addr2line/addr2line.c

453

It looks like we do not do anything with off. Do we need it at all?

463

Uneeded parens.

487

break here?

[tig_freebsdfoundation.org]

1. I fixed the issues mentioned in the code comments.
2. I tested the performance with curlopc and with resetting cu to first cu every time(v2), below is the results:

r=reverse
seq=sequential
rand=random
v1 is addr2line with curlopc
v2 is the version that resets cu to first cu for every translation
10000seq stores 10k sorted addr of first 20k kernel addr.
1000rand stores 1k rand addr in all of kernel addr
r10000seq is 10000seq reversed
Which version should I keep?

3. I didn't test with -f -i before. And having tested it just now I realized the output between the old version and my patch looks different. I'm looking into it now.

[tig_freebsdfoundation.org]

-f and -i flag outputs are now the same as original.
collect_func() needs gdb to get function name, so I added a field a CU to store this info in the cache.

[markj]

In D23501#517304, @tig_freebsdfoundation.org wrote:

2. I tested the performance with curlopc and with resetting cu to first cu every time(v2), below is the results:

r=reverse
seq=sequential
rand=random
v1 is addr2line with curlopc
v2 is the version that resets cu to first cu for every translation
10000seq stores 10k sorted addr of first 20k kernel addr.
1000rand stores 1k rand addr in all of kernel addr
r10000seq is 10000seq reversed
Which version should I keep?

Ok. I am surprised that the difference is so substantial, and that curlopc helps even with reverse-sorted input. I think it is fine to keep it as-is then. I would still like to have a cleaner way to maintain a CU iterator, but I don't have any good suggestions at the moment.

contrib/elftoolchain/addr2line/addr2line.c

417

I think a short comment explaining what this function does would be appropriate.

[tig_freebsdfoundation.org]

Added comment on check_range()

[tig_freebsdfoundation.org]

I added in line 482

if (lopc == curlopc)
				return (DW_DLV_ERROR);

for the case when DW_AT_Range is present so the program stops when we can't find an address.

[tig_freebsdfoundation.org]

This comment was removed by tig_freebsdfoundation.org.