On Tue, 2 May 2023 14:35:22 GMT, Martin Doerr <mdo...@openjdk.org> wrote:
> Do you have for more changes to wait for or would you prefer to have this PR > integrated soon? I don't have anything else in the pipeline at the moment. > Off topic: I have read parts of the Big Endian ABI and we will need a > solution for "An aggregate or union smaller than one doubleword in size is > padded so that it appears in the least significant bits of the doubleword. > All others are padded, if necessary, at their tail." The tail padding seems > to be tricky for Big Endian as we currently access the wrong bytes. I think > it could be solved by dirty hacks (shifting) in the backend, but that doesn't > sound like a good solution. Do you have a good idea for that? Maybe shift or > pad in Java? In general the assumption of the linker is that any layouts it is given are correct for the given platform/ABI. i.e. it is up to the user to specify the correct padding (and this is where jextract can help out a lot). We do also check that layouts are 'canonical' now (see https://github.com/openjdk/jdk/pull/13164 & [1]). I think this already guarantees that the necessary trailing padding is present (constraint 3)? Did you see the discussion at [2] ? I think we already have Big Endian covered? [1]: https://github.com/openjdk/jdk/blob/a8bf2acb7db63b508ef169e42a27b9c99178cbb1/src/java.base/share/classes/java/lang/foreign/Linker.java#L200-L209) [2]: https://github.com/openjdk/panama-foreign/pull/806#discussion_r1122138401 ------------- PR Comment: https://git.openjdk.org/jdk/pull/12708#issuecomment-1531615390
