introduce overridable clear_cache emitter

Olivier Hainque hainque@adacore.com
Mon Nov 16 18:20:07 GMT 2020


Hi Alex,

Thanks for your proposal on this!

> On 11 Nov 2020, at 03:35, Alexandre Oliva <oliva@adacore.com> wrote:
> 
> This patch introduces maybe_emit_call_builtin___clear_cache for the
> builtin expander machinery and the trampoline initializers to use to
> clear the instruction cache, removing a source of inconsistencies and
> subtle errors in low-level machinery.
> 
> I've adjusted all trampoline_init implementations that used to issue
> explicit calls to __clear_cache or similar to use this new primitive.
> 
> Specifically on vxworks targets, we needed to drop the __clear_cache
> symbol in libgcc, for reasons related with linking that I didn't need
> to understand, and we wanted to call cacheTextUpdate directly, despite
> the different calling conventions: the second argument is a length
> rather than the end address.

The initial VxWorks issue is essentially that recent (llvm based)
environments know __clear_cache as a builtin and refuse to statically
link modules that contain an exposed symbol with that name.

As VxWorks (indeed) has a public API for the kind of insn
cache clearing operations we need, it just seems natural to arrange
to call it directly instead of going through an intermediate wrapper
in libgcc. This is a bit more efficient and removes a dependency
on libgcc, a good thing in an environment where there are multiple
ways to link things together.

It also seems like a positive thing to tighten the
connection/consistency between what trampolines and __builtin_clear_cache
do, as they're supposed to be used for similar purposes AFAICT.

> So I introduced a target hook to enable target OS-level overriding of
> builtin __clear_cache call emission, retaining nearly (*) the same
> logic to govern the decision on whether to emit a call (or nothing, or
> a machine-dependent insn) but enabling a call to a target
> system-defined function with different calling conventions to be
> issued, without having to modify .md files of the various
> architectures supported by the target system to introduce or modify
> clear_cache insns.

No strong feeling on the means here, so I'll defer to other
maintainers on the approach.

IIUC, the patch intends not to change the behavior of back-ends on
the trampoline init paths, which seems like a key property to me.

Olivier




More information about the Gcc-patches mailing list