The StringPrinter class was using a Process instance to read memory.
This automatically prevented it from working before starting the
program.
This patch changes the class to use the Target object for reading
memory, as targets are always available. This required moving
ReadStringFromMemory from Process to Target.
This is sufficient to make frame/target variable work, but further
changes are necessary for the expression evaluator. Preliminary analysis
indicates the failures are due to the expression result ValueObjects
failing to provide an address, presumably because we're operating on
file addresses before starting. I haven't looked into what would it take
to make that work.
ReadCStringFromMemory (both flavors) set "force_live_memory" to be true. Note that doesn't mean "don't read from the target" it means "always read from the process first." It does fall back to the Target if there's no process, AND if your Address is section relative.
OTOH, you make it a default argument and then set it to "false" - the opposite behavior. Is there a reason for that? That seems confusing.
force_live_memory is really an efficiency thing. It will only make a difference if the data to be read is in a read-only section of a binary, in which case it will read from there. lldb always used to prefer reading locally if it can, but if someone has been able to flip permissions and overwrite read-only DATA through some kind of attack, you wouldn't be able to see that if this is the default. So in actual fact, we pass force_live_memory -> true most of the places we use these Target Memory Reading API's.
So it seems better to follow ReadCStringFromMemory and just force this to true.