ARM-software / tarmac-trace-utilities

Tools for analyzing and browsing Tarmac instruction traces.
Apache License 2.0
67 stars 22 forks source link

Support multiple ELF images #11

Open rfried-nrl opened 1 year ago

rfried-nrl commented 1 year ago

We're currently tracing our boot ROM and bootloader, and we're jumping between several ELF: BL1, BL2, BL31 & BL33. We would like to have the option to supply multiple ELF files. Is it possible ?

MikeMiller567 commented 1 year ago

I have a similar situation where this would be helpful. In looking at the source, it seems like this would be possible. The tricky part might be altering the options parsers to take multiple filenames and plumbing that code down into the creation of the Image object. I think that would need to be done for each of the applications. Are there specific apps that you were interested in?

statham-arm commented 1 year ago

On the contrary, I think that option-parsing change should be easy to make just once across all the TTU tools, because --image is processed centrally in the TarmacUtilityBase constructor, shared by all tools that take the option at all. You'd just make the image_filename member variable into a vector, and handle that option by pushing another string on it.

The only question is whether it would be better to make the Image class able to aggregate data from multiple ELF images, or to make IndexNavigator able to store more than one instance of Image.

MikeMiller567 commented 1 year ago

Thanks Simon - you clearly know the code better than I do :-)

I feel multiple Image objects would be better so that if we need to keep track of which symbol came from which elf image that data is already preserved, and we have minimal code change to that object.

Would it be weird to create a new Images object that presents a similar API to Image but all its functions iterate over a set of Image objects so that IndexNavigator switches to using Images but is otherwise unmodified and doesn't need to be "aware" that multiple Image objects have been created?

statham-arm commented 1 year ago

I was wondering that myself. Yes, that might well be a sensible approach, because it would avoid having to write separate loops at all the Image call sites in IndexNavigator, and on the other hand, keep Image simple.

MikeMiller567 commented 1 year ago

Do we think there are any potential performance implications to having multiple Image objects as opposed to a "big" image? I haven't profiled any of this code, so I don't know where the possible performance issues are.

statham-arm commented 1 year ago

I can't imagine that it's significant. ELF image symbol lookups happen when displaying a trace line, or when evaluating an expression entered by the user. In both cases, there will be at most a small number of them per UI action, so it's not going to be happening in a hot loop context or anything like that.

ostannard commented 2 months ago

This would also be useful for testing CMSE code, where we use separate ELF images for the secure and non-secure code.