[foreign-abi] RFR: 8248560: Specify the behaviour of the ForeignLinker returned by CSupport::getSystemLinker [v2]

[Jorn Vernee]

On Wed, 16 Sep 2020 10:25:20 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> I added this for fixing jextract. Jextract needs to filter out these attributes before making condys, since otherwise
>> you get an access error when resolving. So, I thought that specifying a common name prefix would be the best way to
>> make that possible, without exposing the actual attribute names that need to be filtered.
>
> not super sure I get this. I imagine that jextact knows well when it needs to emit a layout corresponding to a
> primitive type, so, if that's the case, it should just emit an access to a static constant in Clinker and be done,
> rather than trying to dissect whatever intermediate layout jextract might have generated internally. I guess what I'm
> saying is - let's say that jextract has some layout with 4 attributes for C_INT; then its backend should just emit an
> access for CLinker.C_INT, and re-add the name attribute, which is really the only important part we need?

Yes, the name and alignment are important, but maybe we'd want to add other attributes in the future? Or maybe not us,
but another tool that wants to emit more attributes. It seemed fair that if we added some attributes that clients were
not allowed to look at, at least we could help them with stripping if needed.

I guess another approach is to not let jextract's Type.Primitive use the CLinker layout constants, but let it generate
it's own ValueLayouts, attach name and alignment attributes, and then copy them over to the condy/source using
withAttribute calls when emitting classes/sources.

-------------

PR: https://git.openjdk.java.net/panama-foreign/pull/327