Thanks for your helpful comments! I think I'm starting to put together a picture of how ReflectionContext is tested. I'll try to summarize the discussion here (mostly to to solidify my own understanding).
Summary: For Augusto's project, we want lldb to use NativeReflectionContext to get precise type information when debugging ELF binaries. The equivalent MachO support is tested in two ways: (1) independently of lldb (via the PipeMemoryReader set up in swift-reflection-test) and (2) with lldb (via a NativeReflectionContext set up to use LLDBMemoryReader). This thread is about making the first kind of test work with ELF binaries: it turns out this is hard to do because magic dyld APIs aren't available.
@Joe_Groff, you had a suggestion for how to fix this:
We could perhaps provide some extra entry points in the Swift runtime that only build in debug builds, which could give swift-reflection-test access to the addresses of the reflection sections as the runtime sees them.
Could you elaborate on what would be needed to make this work? Is the idea to record the start/end of the swift reflection sections in a PT_NOTE, like @compnerd described?
I'll throw an alternative half-baked idea out there: could we get swift-reflection-test to spawn the test process under lldb? It should be possible to write a lldb script that computes the result for sendReflectionInfos and injects it into a string inside of the test process.
CC'ing @dcci & @Frederic_Riss since they may have some opinions about this as well.