Week 2

11th of January

Started the day with a brief chat with Brad, who mentioned that the if all goes well the money will be sorted by this week, and also reminded to chase up Yuval again with respect to access to the quad core machine.

I spent the morning reading over the output assembly for the qemu and qemu with llvm, and realised that the assembly output from the llvm version was a lot longer then the standard qemu version. I looked into that for a while at first I thought I had labelled to files wrong way, then saw that the appropriate one ad the generated and replacing statements that only Andrew’s LLVM version has. Next I decided to check what the benchmark timing, and yes, there was that relation of instruction count to run time, the standard qemu one ran faster. I was confused as I was sure, Andrew had seen benefits. At this time I could not contact him, and wasn’t until late in the afternoon he confirmed that this was typical, and that the table in the thesis confirmed this.

In the meantime, there were two other tests I wanted to run (well one new test and one observation from the results of ones I had perform. The first was if you run qemu-arm multiple times will it indeed always produce the same output assembly, similarly with the llvm version. My thoughts would be yes for standard, but maybe not for llvm. Since qemu would always see the same code and apply the same template, where as llvm it depends on when the optimization thread is run, and when its replaced.

The results from this is standard qemu was how I thought, the only difference in assembly output was that the memory addresses were different. The llvm one was the same, the output code was the same, the added difference was where the lines saying generated and replacing were. The Other test I performed was to make sure the reason i was getting the results above (llvm version being slower), was not due to improvements in qemu-arm since 0.10.6 which qemu-async-llvm is based. So grabbed the source code for 0.10.6 compiled it and conducted the same tests. The results from this was the same as if you run the tests multiple times with qemu (the memory addresses were the only thing that different).

As additional step for further exploring and possibly more test cases, I setup a stage3 Gentoo for arm (extracted the system) and attempted to use that as the base path (-L) and binaries from that and the existing test binaries. Ran into problems with that it would just sit there with no output and seem to be doing something but not show anything. I used debootstrap (which is similar to above) but it pulls packages from the the internet. Same problem with that. I then stumbled on the useful strace tool, strace is a tool for tracing system calls and signals, so it can show you what system calls a given program is making.

Using this, it showed that qemu-arm was trying to open /opt/arm/dev/fd/3/dev/fd/3/dev/fd/3/dev/fd/3/….., and recursively going up, searching for files. Brief search on the internet, found this was a common problem, one that had since apparently been fixed, since 0.10.x, however I think this scenario was not 100 percent the same to the one described in the bug report (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=297572), to solve i just deleted the dev directory, and presto it worked. It does however seem weird behaviour that its searching like that, but anyway, it worked. That fixed both the gentoo and Debian version.

debpackget – Script

The last thing I worked on was more a side-project of mine, that had an application for this project. A script for grabbing a package for Debian, that didn’t rely fully on dpkg/apt. Quite simply it grabs the page http://packages.debian.org/\$DISTRO/\$ARCH/\$NAME/download then finds the download link from the mirror we want, so http://ftp.au.debian.org/debian since this is free quota at the University. I then set it up to wget it. Thinking of it as I write this a bash script could of done, by wgeting the download page to tmp file, greping/awking the temp file for the download link, followed by another link. However I wrote it in python so it can be expanded, will probably drop the wget dependency (uses system(.)). Then I coupled this with a call to run dpkg-deb -x \$filename \$outputpath, so it can extract the deb file into the appropriate location. This is not the right place for further discussing this but, it the best place for me to write it down and have it tied. New features:

  • Grab the sources for packages, and extract them (like apt-get source packagename), but not limited to a Debian host
  • Command line options for specifying the destination path, arch and distrbution
  • Switch wget usage to use pythons file downloaded. (Done)