static inline and jextract
Maurizio Cimadamore
maurizio.cimadamore at oracle.com
Tue Sep 6 14:36:54 UTC 2022
Some replies inline:
On 06/09/2022 15:08, Manuel Bleichenbacher wrote:
> 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.
I agree this is the most idiomatic way to do things.
>
> 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).
I also agree that these two seem suspicious. While in a standalone
application, an header containg symbols like these might make sense, in
a library, this most likely does not make any sense, as it will create
storage in all clients importing the headerfile.
>
> 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.
Yes, this seems to be special and unique to Windows. But, I'd rather
gate on presence of "extern", than to obscure __declspec.
>
> 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).
These seem easier, since declaration says "static".
It seems to me that all this boil to two rules:
* we should only generate global var accessor for "extern" variables
* we should skip static symbols (this is covered by [1])
Maurizio
[1] - https://github.com/openjdk/jextract/pull/70
>
> 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/c573a39b/attachment-0001.htm>
More information about the jextract-dev
mailing list