(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, <i>Compiler Validation via Equivalence Modulo Inputs</i>[1], to test ARM compilers.<p>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.<p>[1]: <a href="http://mehrdadafshari.com/emi/paper.pdf" rel="nofollow">http://mehrdadafshari.com/emi/paper.pdf</a>
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.<p>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!
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.<p>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.<p>[1] Underpowered according to FS's own recommended specs.<p>[2] FS also uses APR, but I'm just bitter that it's virtually impossible to cross-compile the Apache <i>Portable</i> Runtime out of the box...