static inline and jextract

[Manuel Bleichenbacher]

I think there are only a few cases:

Case 1: extern int i;
It is a declaration and should generate the lookup for a symbol "i" (plus a
method to get the value). It is already implemented like this.

Case 2: int i = 4;
It can be skipped as it never appears in a header file that can be consumed
by multiple compilation units (as it would generate an error). It's simply
not relevant for jextract, which generates code to access an existing
library.

Case 3: int i;
It is the same as case 2 (implicitly initializes to 0).

Case 4: int __declspec(selectany) i = 4;
This is a special case *and most likely Microsoft specific). In theory, the
behavior could be replicated, i.e. a variable or constant is allocated in
native memory and properly initialized. Since it's a rare case, I'd rather
skip it.

Case 5: static int i = 4;
It is a mixture between case 2 and 4. It's unlikely to appear in header
files although it does not generate an error. The behavior could be
replicated but I would spend time on more important things and skip it for
now.

Case 6: static int i;
It is the same as case 5 (implicitly initializes to 0).

On Tue, Sep 6, 2022 at 3:29 PM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> Hi,
> I think there's more to it.
>
> On Linux, if I do the following:
>
> ```
> $ cat foo.h
> int i = 4;
> ```
>
> and:
>
> ```
> $ cat foo.c
> #include "foo.h"
> ```
>
> And then I compile into a shared lib, the obtained foo.so does have a
> symbol for "i" (rightfully so):
>
> ```
> $ objdump -T foo.so
>
> foo.so:     file format elf64-x86-64
>
> DYNAMIC SYMBOL TABLE:
> 0000000000000000  w   D  *UND*    0000000000000000 __cxa_finalize
> 0000000000000000  w   D  *UND*    0000000000000000
> _ITM_registerTMCloneTable
> 0000000000000000  w   D  *UND*    0000000000000000
> _ITM_deregisterTMCloneTable
> 0000000000000000  w   D  *UND*    0000000000000000 __gmon_start__
> 0000000000004020 g    DO .data    0000000000000004 i
>
> ```
>
> E.g. the above header contains a *definition*, so the compiler will create
> storage for it (and add it to the shared library), and "i" can be looked up
> in the shared lib. Conversely, a global marked as "extern" might or might
> not be present in the shared library (depending on whether it's defined in
> one of the associated C/CPP files).
>
> Maurizio
>
>
> On 06/09/2022 13:57, Manuel Bleichenbacher wrote:
>
> There are two indications that it's definition and not a declaration:
>
> - absence of "extern" keyword
> - presence of initialization ( = { 0x... )
>
> If it was compiled as C/C++ code, it would allocate memory in the current
> compilation unit while a declaration would just refer to something outside
> the compilation unit.
>
> Definitions are rare in header files as they usually lead to duplicate
> symbol errors at link time. But through the magic of __declspec(selectany),
> this is avoided.
>
> On Tue, Sep 6, 2022 at 12:11 PM Maurizio Cimadamore <
> maurizio.cimadamore at oracle.com> wrote:
>
>>
>> On 05/09/2022 16:32, Manuel Bleichenbacher wrote:
>> > extern "C" const GUID __declspec(selectany) GUID_DEVINTERFACE_USB_DEVICE
>> >     = { 0xA5DCBF10L, 0x6530, 0x11D2, { 0x90, 0x1F,  0x00,  0xC0,
>> >  0x4F,  0xB9,  0x51,  0xED } };
>> >
>> I guess the problem here is the lack of "dllexport", right?
>>
>> But, while dllexport is common, some libraries can still export symbols
>> using a .def file [1].
>>
>> So, I'm not sure this belongs in the same category as "static inline",
>> as it is not possible, just by looking at the header, to understand
>> whether the symbol will be present or not?
>>
>> [1] -
>>
>> https://docs.microsoft.com/en-us/cpp/build/exporting-from-a-dll-using-def-files?view=msvc-170
>> <https://urldefense.com/v3/__https://docs.microsoft.com/en-us/cpp/build/exporting-from-a-dll-using-def-files?view=msvc-170__;!!ACWV5N9M2RV99hQ!IZ9OZ1GPWyZCLxdiYrnGJewYmhC_BCpH8sxH4Lo2jBtSsuMJPH_j3-vIXRO1emIKo2SMrT3Sj1AqI3daPLx2VOq6oGrpPgb-Xw$>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jextract-dev/attachments/20220906/1debcd1a/attachment-0001.htm>