libcextract: SymbolExternalizer: Drop klpe_ prefix if IBT is specified

[marcosps]

The resulting code would be exactly the same as the original code, or at least as much as it can be the same.

[giulianobelinassi]

It is not that simple. The way you are doing this you are going to update every reference to the function or variable with a new name that is equal to the name of the old function. That is unnecessary and will result in unnecessary header expansions. You should instead skip the update of those symbols.

And please rebase it on top of the latest branch, as this conflicts with the LateExternalization :) .

[marcosps]

It is not that simple. The way you are doing this you are going to update every reference to the function or variable with a new name that is equal to the name of the old function. That is unnecessary and will result in unnecessary header expansions. You should instead skip the update of those symbols.

And please rebase it on top of the latest branch, as this conflicts with the LateExternalization :) .

But I still need to include the outstr, to add the KLP_RELOC_SYMBOL macro. Or can I just add these symbols at the end > like I'm doing for klp-ccp?

You will need to rewrite the declaration of the symbol, yes. But you do not need to change any use of the symbol.

Adding them at the end will most likely break the one-definition rule. If it doesn't, then yes, it would be just better to add them to the end of the file. That will remove any necessity of header expansion.

In not like this, how can I add the symbol to the final closure without rewriting it, and still adding the extert ...
KLP_RELOC_SYMBOL macro?

At the SymbolExternalizer we do not work with printing what is in the closure, but rather modifying the source file. That is why we provide the Insert_Text, Remove_Text and Replace_Text methods. If you want to append stuff at the end of the file, just Insert_Text with a SourceLocation that reflects it. See SourceManager::getLocForEndOfFile and SourceManager::getMainFileID

Now with regard to the closure, if the Decl you are externalizing is being referenced by the function you want to extract or any of its dependencies, then it will be dragged to the closure by consequence. We do not eliminate any redeclarations.

[marcosps]

@giulianobelinassi please take a look in this new version of the patch. I found some issues with this approach, because it seems that it trigger different header expansion to some LPs tested (thanks to my klp-build test.sh script now I can test if changes like this ripple over previously working LPs...)

I'm sure that I'm forgetting something...

[marcosps]

This one was superseded by #101