[PATCH] D97694: [lli] Test debug support in RuntimeDyld with built-in functions

Stefan Gränitz via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Mar 2 01:33:14 PST 2021


sgraenitz added a comment.

In D97694#2596188 <https://reviews.llvm.org/D97694#2596188>, @lhames wrote:

>> I can imagine tests like these will be handy for testing advanced JIT features inside LLVM in the future. Adding the -generate flag with a hard-coded set of options was not my preferred solution, but all other attempts failed for portability reasons. I am happy to discuss ideas how to improve it.
>
> What other options did you consider?

In my first approach in D97337 <https://reviews.llvm.org/D97337> I put all the code in IR, but I didn't get the dumping via printf to work cross platform. I considered platform-specific versions, but they appear a lot less attractive, because they add much extra work and they would be restricted to test only their native object formats. In a second approach, I moved the dumping code to an external C file and compiled it to the LLVM build-tree with the native toolchain. The idea was to add it to the execution session with the `-extra-objects` command line option. Unfortunately, it shows the same limitation as the "IR in platform-specific versions" approach. Due to mangling differences it's restricted to its native object format: leading underscore with MachO, MSVC mangling with COFF (and in lookups ORC assumes mangling to be identical across all translation units). As a result, the lookup of printf failed (for ELF on MachO e.g. it was looking for _printf).

> How about a list of strings, rather than hard-coded options?
> Or writing `__dump_jit_debug_descriptor` and `__dump_jit_debug_objects` as extern "C" functions and dispensing with the generator entirely (they'd be picked up as process symbols)?

I considered that, but as they are built-ins, they would still be hard-coded eventually. For the reader it would obfuscate the connection between the command line argument and the implementation of a built-in. The user couldn't lookup valid argument values anymore (via `lli --help-hidden`). Also, `__dump_jit_debug_objects` has an extra requirement: it needs to create a tool output stream to append the debug objects. With a static function it required a global static pointer in the same way as I use it now for the generator.

> I think you can land this as-is and we can revise the design later if we come up with a better approach.

Yes let's do that. It's all in the lli tool and not in libraries, so there is no risk to break client code.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D97694/new/

https://reviews.llvm.org/D97694



More information about the llvm-commits mailing list