[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [cdt-dev] Elf Profiling and potential improvements
|
Hello Matthew,
Thanks a lot for sharing the result of your work with community!
The idea to switch to "iterable" style is definitely the right step
forward. We already started a discussion regarding implementation
details in Gerrit.
As for API - we have an opportunity to make it much better, as we
plan a major version bump (to 10.0) in September.
I suggest to start working on the new API in the (not yet created)
"org.eclipse.cdt.binutils" bundle - current implementation may
depend on it but not vice-versa.
The idea of "org.eclipse.cdt.binutils" is to focus on utilities for
binaries itself (.elf, .dwarf, others), without involving CDT Core,
UI and so on. Ideally it should not have any dependency that
requires OSGi running. Yes, to be CLI-friendly. Then we can add
"org.eclipse.cdt.binutils.workspace" to integrate with IWorkspace,
"org.eclipse.cdt.binutils.jface" - to provide preferences, wizards
and editors, and so on.
Why? To keep our dependencies clear and to avoid the fate of the
current CDT Core/CDT UI.
Regards,
AF
03.04.2020 6:28, Matthew Khouzam пишет:
Hello world,
I have been profiling CDT's elf parser, and have found some
opportunities. Now please understand, I was torture testing it
to make sure it works with Trace Compass for some upcoming
feature ideas I was going to pitch, I'm just hoping to help more
than myself with this effort.
I was testing an embedded system with a 1 GB executable. Why? in
case someone else does that. Elf parsing works well and scaled
OK. But the memory requirements are a bit high.
Basically the parser loads every symbol into an array then sorts
it. See image below for a "smaller" test with 60k functions.
I have made a quick patch to allow iteration through the elf
file instead of reading it all in one block. This is useful
when you want to make a map of symbols to trace segments.
I have questions about the API of that file though, it has
many public/protected fields that kind of limit its
modify-ability, what would be the CDT friendly way to improve
it?
My endgame would be to have an iterator on the executable that
gives all the symbols, not necessarily in order so an extender
can use it with more degrees of freedom.
Thanks!
Matthew
Ericsson
Matthew Khouzam
Software Developer
Ericsson
8275 Route Transcanadienne
H4S 0B6,Saint-Laurent, Quebec
Canada
Our commitment to Technology for Good and Diversity and
Inclusion contributes to positive change.
Follow us on: Facebook LinkedIn Twitter
Legal entity:ERICSSON AB registration number 556056-6258,
registered office in Stockholm
This communication is confidential. Our email terms:
https://www.ericsson.com/en/legal/privacy/email-disclaimer
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev