[llvm-bugs] [Bug 47872] New: Link failure with LLVM gold plugin when embedded bitcode is involved for e.g. probe-stack symbol

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=47872

            Bug ID: 47872
           Summary: Link failure with LLVM gold plugin when embedded
                    bitcode is involved for e.g. probe-stack symbol
           Product: tools
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: gold-plugin
          Assignee: unassignedbugs at nondot.org
          Reporter: mh+llvm at glandium.org
                CC: llvm-bugs at lists.llvm.org

Created attachment 24071
  --> https://bugs.llvm.org/attachment.cgi?id=24071&action=edit
Testcase

Unzip the testcase (all files will extract in the current directory), and run
`make all -k`

This is reduced from
https://github.com/rust-lang/rust/issues/74657#issuecomment-668154580, with
added variants.

You'll see that main*.bfd, as well as main2.gold and main4.gold with `undefined
reference to 'probestack'`.

A little explainer of what's going on:
- we create:
  - a main.o bitcode file that uses a "probestack" symbol as a probe-stack for
the `main` function.
  - a probestack.o ELF file that contains both bitcode and machine code for a
dummy function.
  - a probestack2_bc.o ELF file that contains the bitcode from probestack.o as
well as machine code with a different static function.
  - a static library for each of the two probestack*.o files.
- we link main.o with each of probestack.o (main2), probestack2_bc.o (main4)
and their corresponding static library (main, main3), with each of BFD ld, gold
and lld.

The probestack2_bc variants are used as confirmation, on success, whether the
linker used the bitcode or the machine code. It turns out lld never uses the
machine code (per main3.lld and main4.lld containing `mov $0x2a,%eax`), and
gold doesn't use the machine code when it succeeds (per main3.gold containing
`mov $0x2a,%eax`).

What happens with BFD is that the bitcode for probestack is never compiled
during runLTO because an add_symbols call for the probestack object doesn't
happen until after runLTO has finished, during the inputs rescan
(`open_input_bfds (statement_list.head, OPEN_BFD_RESCAN);`)

This in turn seems to be due to the plugin not marking the probestack symbol as
being a requirement of main.o in the first place. If you add an explicit call
to `probestack()` in `main()`, it is marked as such, and all the link commands
succeed. It is worth noting that in that case, probestack is then compiled from
the bitcode for both bfd and gold (but not lld).

Note this problem also affects other symbols than the one used for the
probe-stack attribute. Symbols that are affected include e.g. __muloti4,
__mulodi4, __udivti3, etc. on x86, or __aeabi_uldivmod, etc. on armv7.

I am not 100% sure the problem lies on the plugin end, but from investigating
the issue and from the various results above, it seemed more likely, if not the
plugin itself, at least to be on LLVM's end.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20201016/c70f0b47/attachment.html>