Preventing exporting of symbols generated

[kayhayen]

Hello,

in my Python compiler Nuitka, I am generating extension modules, and will now start using incbin after previously working with linker options to include stuff directly, but LTO came in the way of that. And then I found your brilliant tool to solve the issue in a way more portable fashion. And it's working very nicely.

However, what I discovered is that the symbols are exported, and what happens is when I load two extension modules, is that they get confused with their read only symbols matching, and then only one gets loaded and the other used wrongly. I have added CRC32 checking, and it fails if the second module is loaded, where otherwise in all of Nuitka this doesn't happen.

I am aware that I can make the symbol names not match, by prefixing randomly, but since the users don't cooperate, I would e.g. have to use the hash. Alternatively I think a linker script might prevent the export of the symbols.

In my use in Nuitka, I only need the data locally, I do not need it to be visible to outside code, i.e. I would be fine if the symbol was static in the C sense, and I was wondering if there was a way to just make it local through incbin. Checking out the assembler man page revealed that there is no such thing as a local symbol for it (of course?). So I tried to empty the declaration of INCBIN_GLOBAL and this results in the symbols not being exported and that seems to work, so I am now having a INCBIN_LOCAL that guards this, and it seems to work, at least the binary extension modules doesn't export the symbols anymore, yet the data seems accessible by the code in the same unit.

I guess, that might make sense to add it as a feature to incbin? I would make a PR with the basic change if you agree.

[graphitemaster]

Yes, failing to supply .extern on the symbols inside the inline assembler will prevent exporting and have them behave as statics local to the translation unit. I'll look at introducing an option for this, if you have some sample code you wouldn't mind sharing that might help as well.

[steve-baker-cradle]

If you're taking a look at this, I'm also trying to remove embedded data symbols from a MacOS binary using "strip" and would appreciate some mechanism to be able to declare symbols as private extern (i.e. using .private_extern rather than .globl).

I'm not sure this is 100% the same case as the original poster, but if there were some way to include both usage cases that'd be great!

[kayhayen]

I had a regression after updating incbin to latest version, attempting to create a reproducer. I am having issues with LTO and incbin I believe. Not sure how to provide the reproducer now.