[XRay] Alternatives to relocations in .text section

Hi llvm-dev,

I'm currently looking for alternatives to the synthetic references that XRay uses to keep some side-tables live, to avoid linker garbage collection from deleting those sections. Before going any further, let me give a backgrounder on what XRay does today.

Background

I think you want to use SHF_LINK_ORDER via !associated metadata. That was the conclusion that the generic-abi mailing list came to when trying to solve a similar problem for sanitizers:
https://groups.google.com/forum/#!searchin/generic-abi/garbage$20collection%7Csort:relevance/generic-abi/_CbBM6T6WeM/LZnqx1KZAQAJ

The side table would end up in a section with the SHF_LINK_ORDER flag set and an sh_link pointing at the text section that its associated with.

Yes, but it is super tricky to do this correctly across all linkers.
See how we handle it in ASan. Also, this is quite bad for object file
size, because now each function section has 2 extra sections - one for
the data, and one for section group, and those aren't free. (section
group is necessary to support legacy linkers)

I think you want to use SHF_LINK_ORDER via !associated metadata. That was the conclusion that the generic-abi mailing list came to when trying to solve a similar problem for sanitizers:
https://groups.google.com/forum/#!searchin/generic-abi/garbage$20collection%7Csort:relevance/generic-abi/_CbBM6T6WeM/LZnqx1KZAQAJ

The side table would end up in a section with the SHF_LINK_ORDER flag set and an sh_link pointing at the text section that its associated with.

Sweet – thanks, Reid!

I’ll go have a read through the discussion there.

Cheers

– Dean

Yes, but it is super tricky to do this correctly across all linkers.
See how we handle it in ASan. Also, this is quite bad for object file
size, because now each function section has 2 extra sections - one for
the data, and one for section group, and those aren’t free. (section
group is necessary to support legacy linkers)

Thanks, Evgenii – sounds reasonable to me. I’ll measure and see whether we can document these binary size costs for XRay to be less of a surprise.

We also already do have quite a bit of side-table information for XRay, maybe this wouldn’t be that much worse (i.e. since we already have the instrumentation map and the function index for instrumented functions, we’re already affecting binary size from that front). :slight_smile:

Cheers