9

I want to know how various compilers implement std::random_device, so I popped it into godbolt.

Unfortunately, the only thing it says is

std::random_device::operator()():
        push    rbp
        mov     rbp, rsp
        sub     rsp, 16
        mov     QWORD PTR [rbp-8], rdi
        mov     rax, QWORD PTR [rbp-8]
        mov     rdi, rax
        call    std::random_device::_M_getval()
        leave
        ret

which is not very helpful. How can I step into the _M_getval() call and examine the assembly there?

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847
user14717
  • 4,757
  • 2
  • 44
  • 68
  • 3
    Instead of the assembly, it will be easier to analyze the source code. For GCC's libstdc++: [random.cc](https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/src/c%2B%2B11/random.cc). – interjay May 21 '19 at 19:49
  • @interjay: Good point, but this is just an example. – user14717 May 21 '19 at 19:52
  • But omg it looks wrong! random_device::result_type random_device::_M_getval() { #if (defined __i386__ || defined __x86_64__) && defined _GLIBCXX_X86_RDRAND if (!_M_file) return __x86_rdrand(); #endif Shouldn't it be __x86__rdseed()? – user14717 May 21 '19 at 19:52
  • Possible duplicate of [How to inline a function from libc with gcc?](https://stackoverflow.com/questions/19657276/how-to-inline-a-function-from-libc-with-gcc) –  May 21 '19 at 19:55
  • @interjay The wikipedia article you linked was really instructing! So if godbold compiler explorer became code explorer it would save us the time necessary to dig inside undocumented code to discover bad surprises! I naively thought random_device read /dev/random! – Oliv May 21 '19 at 20:15
  • @Frank: no, [How to inline a function from libc with gcc?](//stackoverflow.com/q/19657276) is not a duplicate. That question is someone that already has access to the asm of a library function (by single-stepping a running executable, which you can't do on Godbolt). And then they copy/pasted from `gdb` disassembly into inline asm statements, making a total mess. Nothing in that question or answer is of any use here. – Peter Cordes May 21 '19 at 20:18
  • 2
    @Oliv: it probably *does* read from `/dev/random`, unless your glibc is compiled with `-march=ivybridge` or newer. (`rdrand` isn't baseline for x86-64! It was new in IvB, and AMD later added support, too.) Or glibc might not define `_GLIBCXX_X86_RDRAND` by default even if it *is* available, because not everyone 100% trusts Intel's black-box RNG not to have subtle patterns introduced by the NSA or something. https://lwn.net/Articles/760584/ is an article about the kernel driver for `/dev/random` and whether it fully trusts `rdrand` (e.g. for early boot-time randomness). – Peter Cordes May 21 '19 at 22:10
  • 1
    @Oliv: oops, I just checked on my desktop. libstdbc++ checks CPUID on init to figure out if `rdrand` is available, and if so uses it. It was pretty simple to step through with GDB (after compiling a `main` that called this function, using `gcc -O3 -fno-plt`). I was fooled by the code the OP posted in a comment, but I guess `_M_file` is how it checks whether to use the `/dev/random` file or not after init. – Peter Cordes May 21 '19 at 22:19

1 Answers1

10

You can't "step into" functions; Godbolt isn't a debugger, it's a disassembler (in "binary" mode, otherwise a compiler asm-text output filter / viewer). Your program doesn't run, it just gets compiled. (And unless you choose the "binary" output option, it only compiles to asm, not to machine code, and doesn't actually link.)

But regardless of terminology, no, you can't get Godbolt to show you disassembly for whatever version of a library it happens to have installed.

Single-step the program on your desktop. (Compile with gcc -O3 -fno-plt to avoid having to step through PLT lazy dynamic linking.)

(I did, and libstdc++ 6.2.1 on Arch Linux runs cpuid in the constructor for std::random_device. If rdrand is available, it uses it on calls to _M_getval(). Figuring this out from just disassembly would have been tricky; there are several levels of function calls and branching, and without symbols it would have been hard to figure out what's what. My Skylake has rdseed available, but it didn't use it. Yes, as you commented, that would be a better choice.)

Different compilers can generate different versions of library functions from the same source, that's the main point of the compiler explorer's existence. And no, it doesn't have a separate version of libstdc++ compiled by every compiler in the dropdown.

There'd be no guarantee that the library code you saw would match what's on your desktop, or anything.

It does actually have x86-64 Linux libraries installed, though, so in theory it would be possible for Godbolt to give you an option to find and disassemble certain library functions, but that functionality does not exist currently. And would only work for targets where the "binary" option is available; I think for most of the cross-compile targets it only has headers not libraries. Or maybe there's some other reason it won't link and disassemble for non-x86 ISAs.

Using -static and binary mode shows stuff, but not what we want.

I tried compiling with -static -fno-plt -fno-exceptions -fno-rtti -nostartfiles -O3 -march=skylake (so rdrand and rdseed would be available in case they got inlined; they don't). -fno-plt is redundant with -static, but it's useful without to remove that clutter.

-static causes the library code to actually end up in the linked binary that Godbolt disassembles. But the output is limited to 500 lines, and the definition of std::random_device::_M_getval() happens not to be near the start of the file.

-nostartfiles avoids cluttering the binary with _start and so on from CRT startup files. I think Godbolt already filters these out of the disassembly, though, because you don't see them in the normal binary output (without -static). You're not going to run the program, so it doesn't matter that the linker couldn't find a _start symbol and just defaulted to putting the ELF entry point at the start of the .text section.

Despite compiling with -fno-exceptions -fno-rtti (so no unwind handler for your function is included), libstdc++ functions were compiled with exception handling enabled. So linking them pulls in boatloads of exception code. The static executable starts out with definitions for functions like std::__throw_bad_exception(): and std::__throw_bad_alloc():

BTW, without -fno-exceptions, there's also a get_random_seed() [clone .cold]: definition, which I think is an unwind handler. It's not a definition of your actual function. Near the start of the static binary is operator new(unsigned long) [clone .cold]: which again I think is libstdc++'s exception-handler code.

I think the .text.cold or .init sections got linked first, unfortunately, so none of the interesting functions are going to be visible in the first 500 lines.

Even if this had worked, it's only binary-mode disassembly, not compiler asm

Even with debug symbols, we wouldn't know which struct member was being accessed, just numeric offsets from registers, because objdump doesn't fill those in.

And with lots of branching, it's hard to follow complicated logic possibilities. Single-stepping at run-time automatically follows the actual path of execution.

Related:

ecm
  • 2,583
  • 4
  • 21
  • 29
Peter Cordes
  • 328,167
  • 45
  • 605
  • 847