jextract error: Crossing storage unit boundaries

[Maurizio Cimadamore]

We are working on a fix - I agree that throwing is too harsh - the fix will report warning if the bitfield cannot be parsed.

Maurizio

On Mon, 2021-02-22 at 18:21 +0000, Duncan Gittins wrote:
Hi Maurizio

Thanks. Maybe jextract needs a "-warn" mode, for the occasions where jextract is used on headers that cannot be fixed. I haven't work out which layout is the trouble-maker in my specific case but fortunately I don't seem to depend on it as my app works fine after I commented out these lines:

StructLayoutComputer.java:
// throw new IllegalStateException("Crossing storage unit boundaries");
LayoutUtils.java:
// throw new IllegalStateException("Cannot infer container layout");

Duncan

On Mon, 22 Feb 2021 at 13:15, Maurizio Cimadamore <maurizio.cimadamore at oracle.com<mailto:maurizio.cimadamore at oracle.com>> wrote:
I'll take a closer look. We did some changes in this area, to fix
issues associated to bitfields parsing.

The new code now works generally better, but is also stricter in
rejecting headers which break some of the invariants that are relied
upon (unfortunately, the underlying issue here is that libclang is not
100% transparent when it comes to bitfield allocation).

My suspicion here is that there is some "pack" pragma involved, and a
bitfield which crosses one storage boundary into the next, which is not
supported.

My feeling is that, in these corner cases, we should try to keep going
with code generation, and issue a warning, rather than completely blow
up code generation.

Maurizio

On Mon, 2021-02-22 at 12:54 +0000, Duncan Gittins wrote:
> I've missed some recent messages so sorry if this repeats anything
> that
> has been reported before or already captured in bug db for ongoing
> fix.
>
> I just pulled latest panama-foreign and rebuilt, the jextract no
> longer
> works on Windows:
>
>      set "WINKIT=c:\Program Files (x86)\Windows
> Kits\10\Include\10.0.18362.0"
>      jextract -source  -lole32   -t duncan.winh -d gen.java --filter
> combaseapi.h  -I "%WINKIT%\um" "%WINKIT%\um\shlobj_core.h"
>
> => fails with message: Crossing storage unit boundaries
>
> Kind regards
>
> Duncan
>

On Mon, 22 Feb 2021 at 13:15, Maurizio Cimadamore <maurizio.cimadamore at oracle.com<mailto:maurizio.cimadamore at oracle.com>> wrote:
I'll take a closer look. We did some changes in this area, to fix
issues associated to bitfields parsing.

The new code now works generally better, but is also stricter in
rejecting headers which break some of the invariants that are relied
upon (unfortunately, the underlying issue here is that libclang is not
100% transparent when it comes to bitfield allocation).

My suspicion here is that there is some "pack" pragma involved, and a
bitfield which crosses one storage boundary into the next, which is not
supported.

My feeling is that, in these corner cases, we should try to keep going
with code generation, and issue a warning, rather than completely blow
up code generation.

Maurizio

On Mon, 2021-02-22 at 12:54 +0000, Duncan Gittins wrote:
> I've missed some recent messages so sorry if this repeats anything
> that
> has been reported before or already captured in bug db for ongoing
> fix.
>
> I just pulled latest panama-foreign and rebuilt, the jextract no
> longer
> works on Windows:
>
>      set "WINKIT=c:\Program Files (x86)\Windows
> Kits\10\Include\10.0.18362.0"
>      jextract -source  -lole32   -t duncan.winh -d gen.java --filter
> combaseapi.h  -I "%WINKIT%\um" "%WINKIT%\um\shlobj_core.h"
>
> => fails with message: Crossing storage unit boundaries
>
> Kind regards
>
> Duncan
>