Initially, I thought _fini is a label in the test case. However, I found, using readelf, that _fini isn't a label in the test case ~/src/elftoolchain/test/elfdump/ts/dso2/test.so. I found it in the symbol table (symtab) instead. Currently, symtab is not checked by addr2line so in order to pass this test a new feature to check symtab is needed.
This patch does help resolve labels addr. For example, when _init is in a DW_TAG_label:

Cleaned up the code/design to make the tool easier to use.

I added functions to find missing ioctl calls. The output has become significantly larger and kind of ugly. I wonder if it's a good idea to let user choose which part they want printed out (normal syscalls vs ioctl.

Here's a sorted version

Should the output list be sorted?

It prints out missing system calls.

Moved readelf revision here

I'll put readelf.c and usr.bin/readelf/Makefile into a separate review

@emaste Yup, I can do that.

Added Version.map diff

In D24566#598950, @emaste wrote:

Added to my staging tree as

diff --git a/contrib/elftoolchain/libelf/Version.map b/contrib/elftoolchain/libelf/Version.map
index e71a59197d0d..ae9783f221ca 100644
--- a/contrib/elftoolchain/libelf/Version.map
+++ b/contrib/elftoolchain/libelf/Version.map
@@ -4,6 +4,7 @@ R1.0 {
 global:
        elf32_checksum;
        elf32_fsize;
+       elf32_getchdr;
        elf32_getehdr;
        elf32_getphdr;
        elf32_getshdr;
@@ -13,6 +14,7 @@ global:
        elf32_xlatetom;
        elf64_checksum;
        elf64_fsize;
+       elf64_getchdr;
        elf64_getehdr;
        elf64_getphdr;
        elf64_getshdr;
@@ -65,6 +67,7 @@ global:
        gelf_checksum;
        gelf_fsize;
        gelf_getcap;
+       gelf_getchdr;
        gelf_getclass;
        gelf_getdyn;
        gelf_getehdr;

In D24327#598927, @yzhong_freebsdfoundation.org wrote:

In D24327#598924, @tig_freebsdfoundation.org wrote:

From my understanding, doing work in the user interface functions is the same as doing work in user program, as they are the same process. It won't be allowed if program is in cap mode.

I understand what you mean. That's why I used pdfork - having the process descriptor lets me wait for the program even in Capability mode. All the current functionality works, so I'd prefer to keep things as it is unless we want the service to do more.

In D24327#598914, @yzhong_freebsdfoundation.org wrote:

Doing the work on the user interface side was a conscious decision on my part. What are the disadvantages of doing it this way? And yes, I do plan to write tests.

From my understanding, doing work in the user interface functions is the same as doing work in user program, as they are the same process. It won't be allowed if program is in cap mode.
exec_command is called by Casper which is a different process, so doing work there is desirable.
It's the pattern I've seen from other Casper services.
I could be wrong though, would appreciate if someone could confirm.

Note that in Casper service user interface and Casper backend are separate processes. Casper does all the work and the user interface simply passes and receives parameters.
One issue I noticed is that the code is doing the actual work (closing fds) in the user interface commands cap_exec_open() and cap_exec_close(), this should be done from exec_command(), perhaps via functions cap_exec_command_open() and cap_exec_command_close(). cap_fileargs.c has a good example of how to do this.
Do you plan to add some test cases?

Sorry, that was my bad. It took me some times to put the diff file together since it was an older patch.

-Added decompression function for Elf_Data.
-Updated Makefiles.
Previous work:
-Add functions to get compression header.

Addressed the comments.

I think all the comments are addressed. Is there anything else that needs to be fixed? Thanks

Please ignore lines 2595-2598 in readelf.c. It was not meant to be added.

Updated license.

update license

Yes that would be great. Please go ahead.

Any further comments? If not, feel free to accept this revision.

It looks like it's just the allocated memory for labels, as most of the memory used by check_labels are given back (freed) according to the picture.
Kernel probably has a lot of assembly files with a lot of labels. Is memory usage a problem?

Check labels seems to be using a lot of memory (20 Mb). There might be a bug somewhere. I'm looking into it.

Added Makefile changes.

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.

Added comment on check_range()

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

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:

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.