On Tue, Jul 04, 2017 at 02:27:00PM +0100, Richard Earnshaw (lists) wrote: > > > > How about omitting the recording step and document that? This way the > > instrumentation can still be useful on e.g. a.out format; the framework > > would then have to check around each function entry whether the NOPs are > > there. > > > > I'm happy with that if the result is still something useful. Frankly, I > don't think GCC has many targets now that don't support named sections, > so I wouldn't loose too much sleep over being unable to support this > feature on such targets. However, if the implementation is straight > forward then doing what you suggest is fine.
Ok, will do it this way then. > > >> The template NOP in default_print_patchable_function_entry needs to be > >> added as a GC root to prevent it being discarded during garbage collection. > > > > Are you sure? For the nop_templ I'm only digging my way to the platform- > > dependent constant string, which I find amongst the constant strings in > > .rodata (or .text, for platforms without named sections ;-). > > Is the memory region pointed to by nop_templ really endangered? > > > > I'd missed that this was trying to recover a string. That's probably OK > from a GC perspective then, but it isn't safe to hold this between > functions since the nop used for one function might not be the same when > we come to the next. Consider, for example, the ARM port where we can > switch from generating ARM code to generating Thumb code: it might work > with the current implementation, but this isn't guaranteed to be the case. I'm "caching" the string, currently. Now that you say it... It will slow things down a bit, but you're right.
