1

Compiler Explorer seems to be able to reliably find the assembly code corresponding to a function. How can I do that myself, assuming a x86_64-unknown-linux-gnu toolchain, a regular (no attributes) function, and without extra tools like cargo-asm?

I know that to produce the assembly, I can use rustc's --emit asm flag. One might think that finding the function is easy as searching for its name in the .s file, but I found that it's not.

For instance, the .s file often doesn't even mention the function name, in which case adding #[inline(never)] to the function helps. Second, having found the label with the function name, how do you determine where the function ends? In my test crate, I found a second mention of the function name in a .size directive farther down – does that maybe mark the end of the function? Or is it maybe the first retq after the function start?

Assuming this goal is achievable, I hope to learn:

  • What are the most reliable ways to find the start and end of a function?
  • What are the prerequisites for getting suitable assembly files to do that?
Peter Cordes
  • 328,167
  • 45
  • 605
  • 847
nnnmmm
  • 7,964
  • 4
  • 22
  • 41
  • 1
    Technically the `.size` can be anywhere but its form is usually `. - foo` where `.` is the current address hence it marks the end of the function. A function may have multiple return instructions so that's not a reliable way to identify it. – Jester May 25 '20 at 18:56
  • 1
    The [source code is available](https://github.com/compiler-explorer/compiler-explorer), presumably containing the answer. – Shepmaster May 25 '20 at 20:16
  • In C/C++, compilers have to produce a stand-alone definition for a function that's not `static`. i.e. that could be called from another translation unit. I don't really know Rust; if that's not the default then maybe you need to mark it as "global" or "exported" somehow. That would still let it inline into some callers as well as making a stand-alone definition, but otherwise achieve the same goal as `inline(never)` – Peter Cordes May 26 '20 at 01:40

1 Answers1

2

Since there was no answer, I did a little bit of research and this should do the trick:

  1. Make sure the function is used by main() in case of a binary crate, or by a pub function in case of a library crate (or is pub itself).
  2. To avoid the compiler inlining your benchmark, mark it #[inline(never)]
  3. Search for the function name, which should find the start, which looks like this:
    .type   <mangled_name>,@function
<mangled_name>:
    .cfi_startproc
  1. Search for the end of the function, which is marked by:
.Lfunc_end<number>:
    .size   <mangled_name>, .Lfunc_end<number>-<mangled_name>
    .cfi_endproc

This can sometimes be preceded by a retq, but not reliably.

Those lines that start with a dot and do not end with a colon, like .type, are directives. The directives that the GNU assembler understands are documented here, and the output of --emit asm should be valid input to the GNU assembler.

Compiler Explorer and cargo-asm

It seems that Compiler Explorer actually keeps the entire file and does not search for functions, it just filters out certain lines. At least that is what the source code seems to be doing.

cargo-asm specifically appears to look for .cfi_endproc on Linux and Mac, and .seh_endproc on Windows.

nnnmmm
  • 7,964
  • 4
  • 22
  • 41
  • Right, Compiler Explorer just filters lines. It works well when you compile a C++ source file that only has a few functions in it. – Peter Cordes Jun 04 '20 at 02:45