Skip to content

test pyelf instead of nm for getting all symbol names+sizes#130

Draft
paulwuertz wants to merge 1 commit intoHBehrens:masterfrom
paulwuertz:feat/pyelf_instead_of_nm
Draft

test pyelf instead of nm for getting all symbol names+sizes#130
paulwuertz wants to merge 1 commit intoHBehrens:masterfrom
paulwuertz:feat/pyelf_instead_of_nm

Conversation

@paulwuertz
Copy link

By using pyelf we are more independet of having any compiler.

For some projects the call to nm -Sl was also very slow. Analyzing the prusa mini firmware for example before was 1470 seconds with 1440 of that the call to nm (see comment #101 (comment)) and with pyelf it only takes 32 seconds.

But some file path and line numbers seem changed, so needs some more investigation...

@W-Mai
Copy link

W-Mai commented Oct 27, 2025

Great work, hope it works properly, it will help a lot. 🚀

@ToddyTsui
Copy link

Great. the origin get_size_lines method does not support ELF file built from clang family. because llvm-nm does not support "-l" argument, Hope your commit can fix this.

@paulwuertz
Copy link
Author

In the binutils it also states at the nm source, that the --line-numbers option will be slow:

/* We need to get the canonical symbols in order to call
bfd_find_nearest_line. This is inefficient, but, then, you
don't have to use --line-numbers. */

As far as I understand it, after the symbols are extracted it searches all the debug symbols for each symbol. Wrapping my head around the macros there seems not so straight forward. Building a map and looking it up may speed nm itself up.

Also the line numbers in the same function further down can be approximate - using either bfd_find_line or bfd_find_nearest_line:

if ((bfd_find_line (abfd, lc->syms, sym, &filename, &lineno)
	       || bfd_find_nearest_line (abfd, bfd_asymbol_section (sym),

so I am unsure - how far the line differences in this change are reasonable.
I think adding some example firmware as a regression suit to puncover and add some tests with the line-number in particular to make sure that things are improved and not worseend.

I was thinking about ELF's of releases of these projects:

If someone has more ideas happy to add more :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants