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

[Jorn Vernee]

On Wed, 16 Sep 2020 10:32:41 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> 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.

I'll remove it for now, and then we can figure out what to do for jextract separately.

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

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