erikvarga

ev3arm writeup

I first put the compiled code into an online decompiler/visualizer, which ended up looking something like

ev3_arm-17958868466f3801c4926675e13863b838e8e7cc
 ├─ MediumMotor.Degrees brake: 0 | port_motor: B | rotations: 35 | speed: -15
 ├─ MediumMotor.Degrees brake: 0 | port_motor: A | rotations: 720 | speed: -75
 ├─ MediumMotor.Degrees brake: 0 | port_motor: B | rotations: 35 | speed: 15
 ├─ MediumMotor.Degrees brake: 0 | port_motor: A | rotations: 360 | speed: 75
 ├─ MediumMotor.Degrees brake: 0 | port_motor: B | rotations: 35 | speed: -15

erikvarga

ev3player writeup

I took a look at the various protocols in the packet log and saw that there was a constant RFCOMM stream lasting several minutes that went back and forth between localhost and LegoSyst_61:30:c1 (EV3). I extracted the raw packet data of the traffic and ran strings on it, which showed a few interesting thing:

../prjs/
../prjs/BrkDL_SAVE/
../prjs/BrkProg_SAVE/
../prjs/SD_Card/
../prjs/SD_Card/project/
../prjs/SD_Card/project/Program.rbf

erikvarga

The goal of my GSoC 2016 project was to improve GCC's Addressing Mode Selection (AMS) pass by:
- Rewriting all of the original code to have a clearer structure and do some things more efficiently
- Fixing the bugs present in the original version
- Implementing further optimization methods to improve AMS's code-size reductions

By the end of the program, I managed to finish the rewrite, fix all but a few remaining bugs and improve the code-size
reductions by adding a new optimization (namely, tracing back the address register's values across previous basic blocks).

Some further work that needs to be done:
- Identifying and fixing any remaining bugs