Open rfried-nrl opened 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?
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
.
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?
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.
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.
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.
This would also be useful for testing CMSE code, where we use separate ELF images for the secure and non-secure code.
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 ?