Minor size_t ABI change in 1.38.10

[Alon Zakai]

On incoming and 1.38.10 we landed

https://github.com/kripken/emscripten/pull/5916

which changes the type of size_t etc. from int to long. This helps synchronize the asm.js and wasm ABIs, and will be convenient for future versions of wasm (wasm64).

This should not be noticeable in most cases, as it remains a 32-bit integer. However, if you depend on the name mangling of a C++ function that uses `size_t` (like in `EXPORTED_FUNCTIONS`), then the name might change slightly ('m' replaces 'j' for size_t). You also need to rebuild source files to bitcode so your bitcode is in sync with the system libraries after they are rebuilt with this change (rebuilding for any new version is recommended anyhow - we rebuild system libraries at that time). Finally, printf of a size_t using %u etc. may now show a warning (but is harmless), which you can avoid with adding a z, %zu etc.

- Alon

[Александр Гурьянов]

I think because with this change now I can't compile protobuf library,
with this error:

protobuf-3.0.2/src/google/protobuf/stubs/once.h:135:30: error: cannot
initialize a parameter of type 'const volatile
google::protobuf::internal::Atomic32 *' (aka 'const volatile int *')
with an lvalue of type 'google::protobuf::ProtobufOnceType *' (aka
'long *')
if (internal::Acquire_Load(once) != ONCE_STATE_DONE) {

I just found this error, I will keep your updated if I can solve it.

вт, 24 июл. 2018 г. в 19:33, Alon Zakai <alon...@gmail.com>:

> --
> You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-disc...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Александр Гурьянов]

I believe that protobuf have this defenition of types (for 32bit build):

typedef int32 Atomic32;
typedef int64 Atomic64;

typedef intptr_t AtomicWord;
typedef internal::AtomicWord ProtobufOnceType;

AtomicWord should be same as Atomic32, so if you say that intptr_t still
remains 32bit integer then easiest fix will be:

Change in atomicops.h defenition of AtomicWord to:

#ifdef EMSCRIPTEN
typedef Atomic32 AtomicWord;
#else
typedef intptr_t AtomicWord;
#endif

This will not be safe if "things" are changed. If I force protobuf to 64bit,
error still there because Atomic64 will be long long, but intptr_t
long. Probably it's
better to compile with -DGOOGLE_PROTOBUF_NO_THREAD_SAFETY, but I never
have success
to building it with that flag.

Anyway now it works.
пт, 27 июл. 2018 г. в 10:58, Александр Гурьянов <caii...@gmail.com>:

[Dan Gohman]

Hello,

The change you described to ProtobufOnceType here seems like it should work. Going forward, this code in newer versions of protobuf has changed and looks like it should avoid this problem. This patch:

https://github.com/google/protobuf/commit/0400cca3236de1ca303af38bf81eab332d042b7c#diff-c1a3f69dda9164a2db00255845f17a34R97

changed the type of ProtobufOnceType.

Dan

> > To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsub...@googlegroups.com.

> > For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsub...@googlegroups.com.

[Sam Clegg]

I'm running into this same issue internally too.

Its seems kind of unfortunate that `intptr_t*` is neither compatible
with `int64_t*` nor `int32_t*`. The code in question (which has thus
far been fairly portable) seems to make this assumption. Could/Should
we change `int32_t*` so that it also `long` and therefore
interchangeable with `size_t`?

>> > > To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-disc...@googlegroups.com.

>> > > For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.

>> To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-disc...@googlegroups.com.

>> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-disc...@googlegroups.com.

[Sam Clegg]

Rather hacky solution: https://reviews.llvm.org/D50477

[Dan Gohman]

One of the main benefits of making size_t be unsigned long is that it eliminates some C++ name mangling differences between wasm32 and wasm64. If we change either int32_t or int64_t, it would introduce new name mangling differences.

If we find more issues, we should reevaluate the options, but so far we only know of one case, and it's already fixed upstream, and there's a workaround posted in this thread as well.

Dan

[Alon Zakai]

There is a second case, a (non-open source) game middleware library, where we saw this too. Same issue, with size_t being implicitly assumed to be one of the int*_t types (so the templates there end up matching nothing).

[Sam Clegg]

Actually, it looks like there are a few other targets that have the
same issue already i386-apple-darwin and i386-pc-openbsd for example
both exhibit the same problem. So I think fixing upstream is the way
to go.