This is an archive of the discontinued LLVM Phabricator instance.

An upcoming patch to LLDB will require the ability to decode base64. This patch adds support for decoding base64 and adds tests.
ClosedPublic

Authored by clayborg on Jun 24 2022, 3:11 PM.

Details

Summary

Resubmission of https://reviews.llvm.org/D126254 with where decodeBase64Byte is no longer a lambda but a static function. Some compilers have different errors or warnings with respect to what needs to be captured and what doesn't (see comments in https://reviews.llvm.org/D126254 for details).

Diff Detail

Event Timeline

clayborg created this revision.Jun 24 2022, 3:11 PM
Herald added a project: Restricted Project. · View Herald TranscriptJun 24 2022, 3:11 PM
clayborg requested review of this revision.Jun 24 2022, 3:11 PM
Herald added a project: Restricted Project. · View Herald TranscriptJun 24 2022, 3:11 PM
llvm/include/llvm/Support/Base64.h
57

Maybe use a more explicit name now that it has file-scope, Base64InvalidByte or something along these line

59

Nit: static const

FWIW, llvm/lib/Object/COFFObjectFile.cpp also contains a decodeBase64StringEntry function that probably should be refactored into using this, if we make a more proper toplevel API for it.

Any updates here? I would love to see this land in some form (haven't looked closely at the patch, but I have several places I would love to use this in MLIR)

clayborg updated this revision to Diff 444371.Jul 13 2022, 11:55 AM

Don't expose the invalid byte definition since this is in a header file. decodeBase64Byte() now makes its own "Inv" version so it can be used to initialize a large array and the name needs to be short, and the decodeBase64() function makes its own version named Base64InvalidByte for readability. No one outside of this header file needs to access this variable so we shouldn't expose it.

For compilation speed I would prefer sinking decodeBase64Byte() into a .cpp file and I would probably also prefer to move the implementation of decodeBase64() even if that means it can no longer be a template and we would need to require i.e., a SmallVectorImpl or something like that. Are there any really big advantages of making this a template?

For compilation speed I would prefer sinking decodeBase64Byte() into a .cpp file and I would probably also prefer to move the implementation of decodeBase64() even if that means it can no longer be a template and we would need to require i.e., a SmallVectorImpl or something like that. Are there any really big advantages of making this a template?

I agree as I was wondering if decodeBase64Byte would cause problems being a static in the header file. I can make a cpp file and remove the template aspect.

For compilation speed I would prefer sinking decodeBase64Byte() into a .cpp file and I would probably also prefer to move the implementation of decodeBase64() even if that means it can no longer be a template and we would need to require i.e., a SmallVectorImpl or something like that. Are there any really big advantages of making this a template?

I agree as I was wondering if decodeBase64Byte would cause problems being a static in the header file.

Outside of commentary on the rest of the patch/design, I can say that making a function namespace (not class) scoped static in a header is a problem, as it leads to ODR violations in any inline function that calls the static one (since every definition of an inline function must be identical, including it must refer to the same entities by name - but the static function is distinct in each TU, so the inline functions refer to different functions (though they have the same name) - so ODR violation). But a direct fix for that in this case would be to make the function inline (think of inline as a linkage, not as telling the compiler to inline the function (it does bias the inliner slightly, but not a big deal) - "inline" just means "let me define this repeatedly, I guarantee all the definitions will be the same"), rather than static.

But yeah, probably moving the definition to the .cpp file is more suitable here in any case.

Hey, I would love to see this landed as well!

clayborg updated this revision to Diff 455750.Aug 25 2022, 4:18 PM

Moved the decoding function to a .cpp file.

aprantl accepted this revision.Aug 30 2022, 3:28 PM

I'm happy with that!

This revision is now accepted and ready to land.Aug 30 2022, 3:28 PM
Mogball accepted this revision.Aug 30 2022, 3:32 PM

awesome!