jextract error: Crossing storage unit boundaries

[Duncan Gittins]

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