Re:Compiler Explorer
by drej on Friday December 14, 2018 @05:57AM
(#18679929)
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
Re:Compiler Explorer
by nyrulez on Friday December 14, 2018 @10:32AM
(#18681481)
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.
Re:Compiler Explorer
by pjmlp on Friday December 14, 2018 @01:43PM
(#18683347)
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.
Re:Compiler Explorer
by pjmlp on Friday December 14, 2018 @02:56PM
(#18684059)
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.
Re:Compiler Explorer
by steveklabnik on Friday December 14, 2018 @03:17PM
(#18684292)
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...
Re:Compiler Explorer
by jokh on Friday December 14, 2018 @11:30AM
(#18682011)
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.
Re:Compiler Explorer
by mshockwave on Friday December 14, 2018 @11:52AM
(#18682238)
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 :-)
Re:Compiler Explorer
by ufo on Friday December 14, 2018 @01:48PM
(#18683402)
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?
Re:Compiler Explorer
by kazinator on Friday December 14, 2018 @05:05PM
(#18685281)
> 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.
Re:Compiler Explorer
by kazinator on Friday December 14, 2018 @05:15PM
(#18685365)
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.
Re:Compiler Explorer
by Const-me on Friday December 14, 2018 @11:56AM
(#18682272)
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.
Re:Compiler Explorer
by sigjuice on Friday December 14, 2018 @05:05PM
(#18685279)
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.
Re:Compiler Explorer
by wyldfire on Friday December 14, 2018 @09:30AM
(#18681009)
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.
Re:Compiler Explorer
by kazinator on Friday December 14, 2018 @05:08PM
(#18685307)
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.
Re:Compiler Explorer
by 0xcde4c3db on Friday December 14, 2018 @09:36AM
(#18681046)
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.
[1] https://github.com/ethanhs/cce
https://github.com/gnzlbg/cargo-asm
(I frequently use Godbolt though, it's so nice for comparing across languages.)
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.
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.
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.
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.
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
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.
C++ is a not a language where i would have a lot of confidence in that limitation!