Autopsy of GCC 4.6.3 compiler bug on Raspberry Pi | Hacker News Reader

Autopsy of GCC 4.6.3 compiler bug on Raspberry Pi

quentusrex.com

39 pointsquentusrex19 comments

(Shameless plug:) It would be great if someone would leverage the pretty successful technique (i.e. found a couple hundred bugs in GCC and Clang) we recently devised to detect miscompilations, Compiler Validation via Equivalence Modulo Inputs[1], to test ARM compilers.

In short, the idea is: profile a program running on a specific input; mutate the unexecuted code with respect to that input; compile and execute the mutated program and expect the output to be identical given the input.

[1]: http://mehrdadafshari.com/emi/paper.pdf

That is extremely clever.

Just curious, how long did that paper take to write (including research time)?

Over a year, I'd say. We'd run the test infrastructure for ~11 months on a couple machines when we submitted the paper.

That's not indicative of much though, as the actual timelines for writing papers can be driven by conference deadlines more than the works themselves (when talking about granularity of six months to a year).

Have you or will you be releasing code for Orion?

We have not, so far. It's a bit difficult to package up as it mostly consists of a bunch of (potentially environment dependent) shell scripts with a transformation program. Shouldn't be too hard to replicate, as the total LOC is pretty low.

Do you have a specific use for it? If so, let me know about it, as I might be able to try lobbying for packaging and releasing the code or work something out.

Nah, I'd just like to take a look at it, but you might be able to get someone else to use it on ARM compilers if you release it.

Very nice. One suggestion, I found the abstract and introduction difficult to understand, and only got the real point by page 3. I would add something clearer in the abstract and/or introduction, such as:

"Static analysis is used to construct alternative versions of the program, that give identical outputs for a given subset of inputs I. The alternative programs are compiled and executed, and we test whether they do actually give the same outputs as the original program, on the input data I. By restricting to a subset I of inputs, a greater variety of alternatives can be produced, than if the alternatives had to be identical to the original program for all inputs."

Link to our talk slides: http://www.cs.ucdavis.edu/~su/publications/emi-talk.pdf

This is only a side point, but I wrote objdump (any objcopy) mainly as a debugging aid when starting to implement bfd. We included it for people porting bfd, rather than as a normal user program.

Thus it is weird, though gratifying, to see it actually used for real work. In fact I use it instead of nm, size, etc but I thought I might be the only one!

Thanks for writing and publishing objdump. I use it often along side of gcc's assembly view. I find the output handy for taking notes, and the format is simple for scripts to parse.

I too find it extremely useful for reading the disassembly of things.

Oh, cool. objdump has been an absolutely crucial part of the process of making my toy kernel.

I used objdump on one project, and I can't thank you enough for it!

I like to use objcopy as a quick way to get a binary blob into a void*.

Interesting, as objdump has long been an indispensable tool... [Is there any other way with the standard GNU toolset to conveniently disassemble a random object/binary? Gdb can of course, but isn't very convenient for doing whole-program disassembly...]

Many thanks for both of these tools!

objdump has been an invaluable part of my debugging toolset over the years, and objcopy has been an indispensable part of the build pipeline we had for the Playstation 3.

What's also interesting is running FreeSWITCH on a RPi. Last time I tried to compile FS on a i686/512MB host [1], GCC OOM'd during linking. And I can't imagine cross-compiling, mostly because I just spent a day fighting an APR cross-compile [2] from x86 to ARM.

But I digress.. awesome bit of detective work in the article. Compiler bugs are really frustrating/tedious to root out, especially if you don't usually muck around with asm.

[1] Underpowered according to FS's own recommended specs.

[2] FS also uses APR, but I'm just bitter that it's virtually impossible to cross-compile the Apache Portable Runtime out of the box...

Try again. There were some major build changes in the FreeSWITCH source tree within the last several months.

I've heard people are able to get a few concurrent calls on the Raspberry Pi, and at least one person turned it into a physical phone.

http://www.switchpi.org/ http://www.switchpi.org/switchpi-proto-lcd-with-dtmf-pad-liv...

Reply on news.ycombinator.com