This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH v9] add -fpatchable-function-entry=N,M option
- From: Torsten Duwe <duwe at suse dot de>
- To: "Richard Earnshaw (lists)" <Richard dot Earnshaw at arm dot com>
- Cc: Sandra Loosemore <sandra at codesourcery dot com>, Maxim Kuvyrkov <maxim dot kuvyrkov at gmail dot com>, Marek Polacek <polacek at redhat dot com>, Maxim Kuvyrkov <maxim dot kuvyrkov at linaro dot org>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Szabolcs Nagy <szabolcs dot nagy at arm dot com>, nd at arm dot com, Li Bin <huawei dot libin at huawei dot com>, Jiri Kosina <jkosina at suse dot cz>, Marcus Shawcroft <Marcus dot Shawcroft at arm dot com>, Takahiro Akashi <takahiro dot akashi at linaro dot org>, Andrew Wafaa <Andrew dot Wafaa at arm dot com>
- Date: Tue, 4 Jul 2017 15:32:50 +0200
- Subject: Re: [PATCH v9] add -fpatchable-function-entry=N,M option
- Authentication-results: sourceware.org; auth=none
- References: <20170613170027.GA16686@suse.de> <fa8b4a2e-9678-d6a6-ff13-9a559e6e408d@arm.com> <20170704131442.GC2376@suse.de> <32457518-5e64-b4a6-e9e9-1aab713e6fc5@arm.com>
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.