48 comments

[ 3.2 ms ] story [ 91.3 ms ] thread
Nice to see this continues to get exposure. It remains awesome and every time I return to it Matt's added some new nifty feature. More please Matt!
See also a command line tool[1] for this, written in Rust.

[1] https://github.com/ethanhs/cce

Neat. But once you're using command line tools why not just use the constituent tools used by Compiler Explorer? `objdump`, etc?
Because it is not written in Rust!!!1!1one

However, something tells me that it has been ported to Rust.

(comment deleted)
And right at the top there's a link to the "diversity" initiative includecpp.org... whose resources happily teach about "Mansplaining", "White Privilege", "Inequality of Pay" and "GoogleBro - Google Memo August 2017 - James Damore". Wow
Matt Godbolt is a great speaker as well. I loved this talk that included a bit about the architecture behind his Compiler Explorer. The rest of his talk is super cool as well. E.g. closed form solutions from O(n) code? Compilers are awesome. https://m.youtube.com/watch?v=bSkpMdDe4g4
#incluide "/etc/passwd" ?
Nothing out of the ordinary there. And the compiling user is not permitted to read /etc/shadow.
Exactly :) Also even if it could, it would be the `/etc/shadow` of the docker container things run in :)
Doesn't look like it works any more.

In any case, Matt Godbolt has spoken a bit about the architecture of Compiler Explorer. Seems like he's given some thought to security.

https://www.youtube.com/watch?v=bSkpMdDe4g4

https://www.youtube.com/watch?v=nAbCKa0FzjQ

IIRC the main sandboxing comes from a wrapper around libc that restricts pathnames used in open() and friends. It seems reasonably well designed for its intent but probably not super difficult to escape. Certainly if the C library adds another entry point, it won't be obvious that there's a new way around.

What the Compiler Explorer has going for it in this regard is that there's very little treasure to be found once you escape. No user accounts, no passwords, no security questions, no financial transactions, etc.

Compiler Explorer doesn't execute the programs it builds, so the risk is limited to what you can convince the compiler/assembler to do on your behalf.

> limited to what you can convince the compiler/assembler to do on your behalf

C++ is a not a language where i would have a lot of confidence in that limitation!

Works for me, you just gotta pass -E in the args. Also need to spell include right.
In the age of shadowed passwords, that doesn't amount to a hill of beans. You already know there is an account called root and probably other common things like daemon and www-data.
No perl?!?!?!?
In a tool to study assembly output of compilers?

    $ perl -MO=Concise -e 'my $v = 1234; $v *= 9876'
    a  <@> leave[1 ref] vKP/REFC ->(end)
    1     <0> enter ->2
    2     <;> nextstate(main 1 -e:1) v:{ ->3
    5     <2> sassign vKS/2 ->6
    3        <$> const[IV 1234] s ->4
    4        <0> padsv[$v:1,2] sRM*/LVINTRO ->5
    6     <;> nextstate(main 2 -e:1) v:{ ->7
    9     <2> multiply[t2] vKS/2 ->a
    7        <0> padsv[$v:1,2] sRM ->8
    8        <$> const[IV 9876] s ->9
    -e syntax OK
This tool is really built for AOT native code generation. Does Perl have a compiler like that? The ones I've heard of are all some flavor of compiling to bytecode followed by an interpreter or JIT.
(comment deleted)
It a very nice project.

I really like how it grew to encompass any language with AOT/JIT compilers, as long as anyone is willing to support the language related tooling.

This is amazing for all computer science degree courses. I wish I had this when I was learning this stuff. Sadly, I think the truth is that most profs or students won't know this platform exists.
Compilers have had the ability do dump Assembly since the early days, and many IDEs do support an interleaved Assembly view, so the missing teaching opportunity has been there for quite a long time.
Even then, I think the great UI in the compiler explorer still puts it apart from the others.
Sure, compiler explorer is a great idea, just saying that unfortunately plenty of people aren't aware of such workflows, even when the tooling has been available for so long.
This would be really useful if it can be run offline. Much easier to use than writing code, compiling it with -S to produce assembly, then trawling through the assembly to look for the code you're interested in.
I haven’t really tried it but from all the exposure godbolt gets in cppcast, I think there is a way to run it locally.
It's open source, so you can just clone the source code and run the server locally on your computer. I've been running it like this for a long time :-)
Oh, I had no idea it was open source. Thanks!
How hard was it to set up for you? Is it a small standalone thing or a beast with complex dependencies? Did you configure it to run everything locally or is it still requesting a web service to compile the programs?
i got it up and running within 30min or so.
If you're interested in the code, put a breakpoint and launch with a debugger. In Visual C++ that literally two keypresses, F9 and F5. As a nice side effect, you can step over the assembly instructions observing how they change registers and memory.
> Much easier to use than writing code compiling it with -S to produce assembly

In any real-world, production use cases, I will vastly prefer to "objdump -d" or "objdump -S" the executable image (which is formed from dozens, hundreds or thousands of source files, with specific compiler flags and so on). I'm not going to be feeding these source inputs into some dialog box on a website.

What you might benefit from would be a browser which can parse the output of "objdump --line-number -S <yourexecutable>" and present it in a nicer way.

E.g. all the implicated source files could be identified and loaded into multiple views/tabs, with two-way navigation between those and the disassembly tab.

Idea: massage the "objdump --line-number -S <executable>" output into a vim quickfix list (errors.err file).

Then run vim -q.

The idea would be that all those file:line entries become navigable quickfix items: we can navigate through the quickfix items (thereby browsing the source code), and the assembly is in the quickfix window as context.

Legit 10/10 for their displayed privacy policy.
Really nice work by Matt. Haven’t seen a project before that makes some of that stuff quite so quick and simple.

Tangentially, anyone have a transpiler recommendation?

Started to look at Babel but it seems most inclined to targeting Javascript. Looking to go bidirectional between Python and a proprietary DSL.

Would have to reverse engineer the DSL grammmar I assume but it doesn’t seem very complex, so hearing of any good tooling would be interesting.

Or, in one line of shell:

  echo 'int square(int num) { return num*num; }' | gcc -S -x c - -o -
How about this: open an editor on "test.c". Then in another terminal window, run this script:

  #!/bin/sh

  rm -f test_copy.c

  while true ; do
    if [ test.c -nt test_copy.c ] ; then
      cp test.c test_copy.c
      clear
      gcc -S test_copy.c -o -
    fi
    sleep 0.3
  done
Every time you save test.c, the compiler output updates in the other shell window (within a fraction of a second).
Godbolt has many more features than this. It can show you mappings from your code to the outputted asm, it can show help text on what instructions mean, you can compare multiple compilers against the same source file easily...
Is there a way to set this up to have two windows? One window to type code into and the other to run my program? I have been fiddling with the UI for a while, but can't quite figure it out.
My bad. For some reason I thought I could actually run programs, but looks like that isn’t the case.