«
»

The Moxielyzer

I just committed a little binary analysis tool to moxiedev. You can use it to perform simple static analysis on moxie binaries. The kinds of things I’m looking for are compiler bugs (because I know there’s still one there that is triggered by -frerun-cse-after-loop), and instruction statistics. For instance, which registers are used as load offsets, and how often? The tool uses a primitive plugin architecture that should make it easy to add new analysis tools in the future. It’s called the moxielyzer, and here is the initial commit. Run it with no arguments to get a list of plugins. Run it with just a plugin name, and it will describe the plugin. Run it with a plugin name as well as an ELF moxie executable filename, and the analysis will be performed.

I had written a similar tool for ggx back in the bad old days. Another option was to hack this stuff into gas, but I prefer to keep gas “clean” (translation: I want the freedom to maintain hacky analysis code).

BTW – I’m also rolling out a new libffi in a few weeks. You can keep track of the release candidate test results on the wiki here.

Tags: ,

This entry was posted on Wednesday, October 14th, 2009 at 10:05 pm and is filed under Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

  • sidmanning

    Hi,
    I tried to get a copy of your git repository using:
    git clone git://github.com/atgreen/moxiedev.git

    However this fails with the following fatal error:
    Initialized empty Git repository in /home/sid/moxie/moxiedev/.git/
    remote: Counting objects: 385449, done.
    remote: Compressing objects: 100% (222676/222676), done.
    fatal: The remote end hung up unexpectedly01 MiB | 875 KiB/s
    fatal: early EOF
    fatal: index-pack failed

    I watch download file in moxiedev/.git/objects grow and it appears to get this EOF between 80 and 100M into the file.

  • atgreen

    What are you running on? I have no problem on Fedora or RHEL, but I've seen this problem on Windows.

  • sidmanning

    I've tried on OpenSuse 11.1 and SUSE Enterprise Server 10.2. I have an FC5 host so I'll give it a try on that and see.
    I started using your port as a reference when it was ggx and used your original patch set as a guide when I was updating one of our targets. That organized the process and made the update of binutils go smoothly.
    Its over a year later and now its time to update GDB. Our current target code is very messy and I've finished the update but there are parts of the tdep that I would like to model after moxie so having a fully working model will help.

    Thanks,

  • atgreen

    Cool. The upstream GDB already contains moxie, so that's another option. But moxiedev is nice because it builds all of the tools for you.

    What kind of target are you working on?

  • sidmanning

    I tried FC5 and OSX with the same results. This is the first time I've used git but after searching I did find a message from a git support site that claims there is a memory leak in a version of git proxy. Since you don't see it, it probably doesn't apply but here is the link to the description:http://support.github.com/discussions/repos/1623-index-pack-failed-on-gitgithubcomelanplexgit

  • sidmanning

    I'm looking at the moxie code in 7.0 base but having a running target to compare against is helpful when I'm trying to figure out bugs.

    The core I'm working on is Qualcomm's QDSP6 it is a high function VLIW processor originally used for signal processing but we have exploited for lots of other things too. We are doing the same thing you did with moxie, get it to run Linux, port uClibc and then re-compile packages. Our existing base tools where all quite old, gdb-6.1 and binutils-2.14.
    (Holy crap! A plane hit a building across the street! I've been watching it from my window…They have finally got the fire under control…Wow.)
    Anyway…The rpm repository gives this error too:
    http://moxielogic.org/yum/MoxieLogic/repodata/r... [Errno 14] HTTP Error 404: Not Found

    This is the whole message, with a ping to show connectivity:
    [root@vadmin src]# yum groupinstall moxiedev
    Loaded plugins: refresh-packagekit
    http://moxielogic.org/yum/MoxieLogic/repodata/r... [Errno 14] HTTP Error 404: Not Found
    Trying other mirror.
    Error: Cannot retrieve repository metadata (repomd.xml) for repository: moxielogic. Please verify its path and try again
    [root@vadmin src]# ping -c 1 moxielogic.org
    PING moxielogic.org (72.167.232.229) 56(84) bytes of data.
    64 bytes from p3nlh090.shr.prod.phx3.secureserver.net (72.167.232.229): icmp_seq=1 ttl=128 time=54.4 ms

  • atgreen

    I just replicated the problem. It seems to be related to read-only clones. I mostly do read/write checkouts, which don't appear to have this problem. I'll notify the github people. Have you tried the “Download Source” button on the top right instead? That might work.

  • atgreen

    A friend just told me that she can see the crash from her hotel window and sent a pic. Crazy.

    I've got to run out for some meetings. I'll follow up tonight.

  • atgreen

    Try again with http://moxielogic.org/download/moxielogic-repo-... and let me know how it works.

  • atgreen

    Read-only cloning is working for me now. You might want to try this again. Thanks!

  • sidmanning

    I got your tree and I'm building now. The only glitch was that I needed to create the …/moxiedev/root/usr/bin directory. When this directory isn't present the sanity check fails when trying to write to that directory

  • sidmanning

    This is the actual message:
    [echo] ====================================================================
    [echo] ====== Verify that PATH is sane ====================================
    [echo] ==================================================================== [exec] mktemp: failed to create file via template `/home/sid/moxie/moxiedev
    /root/usr/bin/tmp.O9UzzAGy9L': No such file or directory
    [exec] ./scripts/precheck/check-path: line 25: $TMPEXE: ambiguous redirect
    [exec] chmod: missing operand after `+x'

  • atgreen
  • sidmanning

    I got side-tracked for a while but I'm able to build having only to make a couple of changes.

    I had to manually download your linux-2.6-moxie and busybox-moxie but afterward the build finished. The HACKING guide implies that the build.xml will pull these trees but they didn't show up for me. The error messages make it plain what was missing so it was no big deal to fix.

    When the build finished I could build and run the programs in the test directory

    The kernel “booted” to the MoxieuClinux banner. I created an ext2 ramfs, copied busybox and then simpler stuff, booted using flags like this:
    ./root/usr/bin/moxie-elf-run -v linux-2.6/vmlinux root=tmp/disk init=sbin/init

    Each the boot ends with a sim_halt:
    Freeing unused kernel memory: 970k freed
    ___ ___ _ _____ _ _
    | / | (_) / __ (_)
    | . . | ___ __ ___ ___ _ _| / / |_ _ __ _ ___ __
    | |/| |/ _ \ / / |/ _ | | | | | | | | '_ | | | / /
    | | | | (_) |> <| | __/ | |_| | __/ | | | | | |_| |> <
    _| |_/___//_/__|___| __,_|____/_|_|_| |_|__,_/_/_
    core: 4 byte read to unmapped address 0xfffffff8 at 0×0
    sim_halt – bad long jump

    I remember that the kernel can be built with an included ramfs and maybe that is missing. I don't need to boot linux but its pretty cool that it gets this far.

    Overall this is great, an excellent reference base.

    Thanks,

  • sidmanning

    Wow that “MoxieuClinux” banner looks much better in my tty

  • atgreen

    Ha.. yes, the banner does look better on a console.

    I have been making many local improvements to the kernel port, but it still doesn't get much further than this yet. I'll try to check-in my work so far tonight.

    I'll also look into the submodule business. I spent a fair amount of time trying to get those modules to checkout automatically.

    BTW – you should be able to just run “moxie-elf-run vmlinux” because the initramfs is built into the kernel image.

    Thanks for your continued feedback!

blog comments powered by Disqus