This is an archive of the discontinued LLVM Phabricator instance.

[XRay] Synthesize a reference to the xray_instr_map
ClosedPublic

Authored by dberris on Aug 11 2016, 3:16 AM.

Details

Summary

Without the synthesized reference to a symbol in the xray_instr_map,
linker section garbage collection will helpfully remove the whole
xray_instr_map section from the final executable (or archive). This will
cause the runtime to not be able to identify the sleds and hot-patch the
calls/jumps into the runtime trampolines.

This change adds a reference from the text section at the end of the
function to keep around the associated xray_instr_map section as well.

We also make sure that we catch this reference in the test.

Diff Detail

Event Timeline

dberris updated this revision to Diff 67667.Aug 11 2016, 3:16 AM
dberris retitled this revision from to [XRay] Synthesize a reference to the xray_instr_map.
dberris updated this object.
dberris added a subscriber: llvm-commits.
mehdi_amini added inline comments.Aug 11 2016, 10:45 AM
test/CodeGen/X86/xray-attribute-instrumentation.ll
2

I don't understand this line, this is the same run as the first line, but for the check-prefix. The intent is not clear.
Note that "CHECK" is the default prefix, used by the first run. But "-LABEL" is a "magic" suffix for FileCheck. So "CHECK-LABEL" is already used by the first check!
See The “CHECK-LABEL:” directive section here: http://llvm.org/docs/CommandGuide/FileCheck.html

mehdi_amini edited edge metadata.Aug 11 2016, 10:47 AM
dberris updated this revision to Diff 67774.Aug 11 2016, 4:41 PM
dberris marked an inline comment as done.
dberris edited edge metadata.
  • Fix use of CHECK-LABEL
test/CodeGen/X86/xray-attribute-instrumentation.ll
2

Whoops -- that was me not understanding what this meant. :/

Fixed.

echristo accepted this revision.Aug 18 2016, 3:17 PM
echristo edited edge metadata.

Not happy with this solution, but it'll work for now :)

-eric

This revision is now accepted and ready to land.Aug 18 2016, 3:17 PM
This revision was automatically updated to reflect the committed changes.
rnk added a subscriber: rnk.Sep 13 2016, 8:12 PM

How does gold know to avoid stripping .init_array sections? If it's not a special case, I wonder if we could try to do what's done there.

In D23398#542014, @rnk wrote:

How does gold know to avoid stripping .init_array sections? If it's not a special case, I wonder if we could try to do what's done there.

Apparently according to @majnemer (please correct me if I'm wrong here) that it's a special case in gold -- so unless we teach gold to treat xray_instr_map sections as special, or find a way to make this an option you can provide as a flag then this seems to be the thing that works for now. I agree we could do better by changing the linkers to do the right thing, but that will take longer.

rnk added a comment.Sep 13 2016, 8:23 PM

My thought was that gold and other linkers could look out for use of the __+section+_start symbol in the final executable, and use that to figure out when to power down --gc-sections. If it's a data (not code) section and the start and end are used, it seems like a pretty solid bet that the user expects to find that data at runtime.

Anyway, the workaround should be fine for now.

majnemer edited edge metadata.Sep 13 2016, 8:28 PM
In D23398#542014, @rnk wrote:

How does gold know to avoid stripping .init_array sections? If it's not a special case, I wonder if we could try to do what's done there.

It is a special case: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=gold/object.cc;h=a631c9937c5f589de5db561e381f161c637bdfde;hb=HEAD#l1618

In D23398#542023, @rnk wrote:

My thought was that gold and other linkers could look out for use of the __+section+_start symbol in the final executable, and use that to figure out when to power down --gc-sections. If it's a data (not code) section and the start and end are used, it seems like a pretty solid bet that the user expects to find that data at runtime.

I expected exactly that behaviour. It was unfortunate to learn that this wasn't the case.

Anyway, the workaround should be fine for now.

Thanks for having a look!

rnk added a comment.Sep 13 2016, 8:54 PM

It says right there that section_start/end symbols will suppress the dead stripping, though:
1625 If the section name XXX can be represented as a C identifier
1626
it cannot be discarded if there are references to
1627
start_XXX and __stop_XXX symbols. These need to be
1628
specially handled.

Maybe we just need to generate two such synthetic references per object file, if the runtime doesn't do enough?