2GB超えメディアへの ipk インストールの道 – その3

前回前々回の続き。

調査を進めるにつれ、SDだけでなく、CFでも同じ問題があることが判明したため、タイトルを変更した。

qinstall.so の InstallUtil::getAvailableSize() で statfs() が呼ばれていることが判明した続き。

statfs前後の処理

statfs をコールする前を確認してみる。

   26e4c:       e1a00004        mov     r0, r4
26e50: ebffa6c1 bl 0x1095c ; call QString::latin1(void) const
26e54: e24b1060 sub r1, fp, #96 ; 0x60
26e58: ebffa617 bl 0x106bc ; call statfs()

statfs を呼び出す前を見ると、第1引数(r0) に QString::latin1() の結果(おそらくパス名が入っていると思われる)が、第2引数(r1) には、fp – 96 (スタック上のローカル変数と思われる)がセットされている。

雰囲気的には以下みたいな感じかな?

unsigned long InstallUtil::getAvailableSize(QString)
{
:
struct statfs stat;
int ret;
ret = statfs(path.latin1(), &stat);
:
}

ふむふむ。

その後を追いかけてみる。(簡単なコメント付き)

   26e58:       ebffa617        bl      0x106bc            ; call statfs()
26e5c: e3500000 cmp r0, #0 ; 0x0 // 戻り値確認
26e60: 0a000008 beq 0x26e88 // 戻り値=0 (正常) なら 0x26e88 へジャンプ
26e64: e3a05000 mov r5, #0 ; 0x0
26e68: ea000009 b 0x26e94
:
:
26e88: e51b205c ldr r2, [fp, -#92] // struct statfs構造体の何かを r2 へ読み出し
26e8c: e51b3050 ldr r3, [fp, -#80] // struct statfs構造体の何かを r3 へ読み出し
26e90: e0050293 mul r5, r3, r2 // r5 = r3*r2
:
26ecc: e1a00005 mov r0, r5 // 上の掛け算結果を r0 へ
26ed0: ea000000 b 0x26ed8
26ed4: 00000800 andeq r0, r0, r0, lsl #16
26ed8: e91bac70 ldmdb fp, {r4, r5, r6, sl, fp, sp, pc} // リターン

struct statfs の何かのメンバ同士を掛け合わせたものが getAvailableSize() 関数の戻り値(r0)に入るようだ。では、statfs の何のメンバなのか。

statfs の第2引数は fp-96 のアドレスだったので、fp-96 から struct statfs 構造体が始まっている。その構造体にアドレスを当てはめると・・・

   struct statfs {
long f_type; /* fp-96 */
long f_bsize; /* fp-92 */
long f_blocks; /* fp-88 */
long f_bfree; /* fp-84 */
long f_bavail; /* fp-80 */
long f_files; /* fp-76 */
long f_ffree; /* fp-72 */
fsid_t f_fsid; /* fp-68 */
long f_namelen; /* fp-64 */
};

fp-92 は f_bsize、fp-80 は f_bavail だと分かる。

man page によると、f_bsizeが「ブロックサイズ」、f_bavail が「非スーパーユーザが使用可能な空きブロック数」らしい。これらを掛け合わせているということは、非スーパーユーザが使用可能な空きバイト数を計算しているということになる。

掛け算で使用している mul という命令は、このページによると 32bit = 32bit * 32bit の符号なし掛け算のようだ。この時点で 4GB (32bit) を越える空き容量は正しく判断できないことが分かる。さらに、4GBSDで問題が起こると言うことは、この結果を singed long として扱っていると推測できる。

また、getAvailableSize() 関数は名前の通り、空き容量をバイト数で返す関数だということも確証が得られた。

さて、これをどうしようか。

空き容量2GBの壁の検証

前々回のブログに対して、Haniwa様から 4GB SD でもインストール可能でしたとのコメントを頂いた。
今までの解析結果と推測から、空き容量が 2GB 前後に壁があるのではないかと考えられる。
ということで、4GB SDにダミーファイルを作成して、空き容量を2GB前後にしてインストール可能/不可能が変わるのかを検証してみた。

その結果・・・

  • 空き容量 2,147,450,880Byte  (0x7FFF8000 Bytes)
    → インストールOK
  • 空き容量 2,147,483,648Byte  (0x80000000Bytes)
    → インストールNG

やはり、空き容量が2GBの所に境界があるようだ。(SL-C1000, SL-C3000 で確認)

ついでに、4GBのCFでも確認してみたところ、やはり 2GB 以上の空き容量の場合はインストールできないようだ。(SL-C1000で確認)

ただし、Haniwa様がお持ちなのは SL-C3200 なので、SL-C3200 では元々 4GB メディアに対応している可能性もある。内蔵MicroDrive は6GBなので、空き容量が2GB越えに対応する必要もありそうだし。(そう考えると SL-C3000で対応済みでもよさそうだが・・・SD/CFへのインストールと本体へのインストールは容量判定処理が別なのだろうか・・・)

修正方針

qinstall.so に手を入れるとすると、修正する方法は2通りある。InstallUtil::getAvailableSize() 関数に手を入れるか、この関数を呼び出した後の判定に手を入れるか。

getAvailableSize() を呼んでいる場所を調べるため、逆アセンブルした結果を bl 0x26d20 で grep したら 13 個も見つかった。これを追うのは気が滅入りそうなので、getAvailableSize()を修正することにした。

また、空き容量が2GB以下であれば、getAvailableSize() の呼出側は正常に動作できるようなので、空き容量が2GB以上の場合は 2GB-1Byteとして返却することにしよう。そうすれば、何GBのメディアでも対応可能だし。

(もう少し続く・・・)


4GSD へ ipk インストールの道 – その2

前回の続き。

qinstall.so に InstallUtil::getAvailableSize(QString) という関数があることが分かった。この辺をなんとかすればいけるかも?

InstallUtil::getAvailableSize の抽出

まず、この関数がどこからどこまでなのかを調べてみる。開始アドレスは前回の objdump の結果から、

00026d20 g    DF .text  000001bc  Base        InstallUtil::getAvailableSize(QString)

0x26d20 だと分かっているので、そこから逆アセンブルしてみる。

$ arm-linux-objdump -d --start-address=0x26d20 qinstall.so | less
      :
00026d20 <.text+0x14bd4>:
   26d20:       e1a0c00d        mov     ip, sp
   26d24:       e92ddc70        stmdb   sp!, {r4, r5, r6, sl, fp, ip, lr, pc}
   26d28:       e24cb004        sub     fp, ip, #4      ; 0x4
   26d2c:       e1a04000        mov     r4, r0
   26d30:       e24b0020        sub     r0, fp, #32     ; 0x20
:

そういえばARMはこんな感じだったっけ。
ARMでは関数の先頭で stmdb でレジスタを保存して、関数の最後に ldmdb でレジスタを復元してリターンするのが典型的なパターン。

そのまま先を見ていくと・・・。

     : 
26ed0: ea000000 b 0x26ed8
26ed4: 00000800 andeq r0, r0, r0, lsl #16
26ed8: e91bac70 ldmdb fp, {r4, r5, r6, sl, fp, sp, pc}

あった ldmdb。

脱線するけど、初めて ARM に触ったときにこの stmdb と ldmdb の仕組みが良くできてて感心した記憶がある。
関数の入り口と出口をならべてみるとよく分かる。

   26d20:       e1a0c00d        mov     ip, sp
   26d24:       e92ddc70        stmdb   sp!, {r4, r5, r6, sl, fp, ip, lr, pc}
   26ed8:       e91bac70        ldmdb   fp, {r4, r5, r6, sl, fp, sp, pc}

r4〜r6, sl, fp は素直に保存・復元が行われて、特に lr が見事で、コール時に保存した戻りアドレスの lr を pc に戻すことでリターンを実現している。
レジスタの復元とリターンが同時にできるなんて、なんてスマートなんだ!!  しかも1命令で!! と感動したのは私だけ?? (^^;

・・・・話を戻すと、getAvailableSize の最後は 0x26ed8 で良さそう。
最適化を行うと、関数の途中にも ldmdb が出てきたりするんだけど、ジャンプを追いかけても 0x26d20〜0x26ed8 の間に収まってるみたい。

とりあえず関数の抽出ができた。

getAvailableSize の調査

本当にこの関数で statfs が呼ばれているのか調べてみる。

関数コールは bl 命令を探すだけでOK。

   26d4c:       ebffa9b6        bl      0x1142c
26d60: ebffaa05 bl 0x1157c
26d9c: ebffa7f2 bl 0x10d6c
26db8: ebffa9e3 bl 0x1154c
26dd0: ebffa995 bl 0x1142c
26de4: ebffa9e4 bl 0x1157c
26e1c: ebffa7d2 bl 0x10d6c
26e34: ebffa9c4 bl 0x1154c
26e48: ebffa9bf bl 0x1154c
26e50: ebffa6c1 bl 0x1095c
26e58: ebffa617 bl 0x106bc
26ec8: ebffa7a7 bl 0x10d6c

コール先がダブっているものを省くと、

   26d4c:       ebffa9b6        bl      0x1142c
26d60: ebffaa05 bl 0x1157c
26d9c: ebffa7f2 bl 0x10d6c
26db8: ebffa9e3 bl 0x1154c
26e50: ebffa6c1 bl 0x1095c
26e58: ebffa617 bl 0x106bc

この6つに絞られた。これを1つ1つ調べてみる。

まずは 0x1142c。このアドレスはどこかというと、

$ LANG=C arm-linux-readelf -S qinstall.so
There are 23 section headers, starting at offset 0x3918c:

Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
:
[10] .init PROGBITS 00010194 010194 000018 00 AX 0 0 4
[11] .plt PROGBITS 000101ac 0101ac 001fa0 04 AX 0 0 4
[12] .text PROGBITS 0001214c 01214c 020da4 00 AX 0 0 4
:

.plt セクションのようだ。.plt セクションは動的リンクしたライブラリへジャンプするためのコードが書かれたもの。

早速 0x1142c を逆アセンブルすると、 

   1142c:       e59fc004        ldr     ip, [pc, #4]    ; 0x11438
   11430:       e08fc00c        add     ip, pc, ip
   11434:       e59cf000        ldr     pc, [ip]
   11438:       0002ef98        muleq   r2, r8, pc

こんな感じのコードだった。C言語風に訳すと、

  • ip = *((unsigned int *)0x11438);
  • ip += 0x11438;
  • pc = *((unsigned int *)ip)    // ipに書かれたアドレスへジャンプ

つまりは、0x2ef98 と 0x11438 を足したアドレスに書かれているアドレスにジャンプするというもの。

足し合わせると、 0x403d0 となる。このアドレスは・・・

$ LANG=C arm-linux-readelf -S qinstall.so
There are 23 section headers, starting at offset 0x3918c:

Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
:
[17] .dtors PROGBITS 0003ff20 037f20 000008 00 WA 0 0 4
[18] .got PROGBITS 0003ff28 037f28 0010d0 04 WA 0 0 4
[19] .dynamic DYNAMIC 00040ff8 038ff8 0000d0 08 WA 3 0 4
:

.got セクションのようだ。.got セクションは、シンボル解決をしたアドレスが書かれるテーブル。

まぁ、白々しくこう書いたけども、.plt がジャンプコードになっていて、.got がそのジャンプアドレステーブルになっているのは ELF の動的リンクの仕組みそのもの。うん。いい勉強になるね。(また白々しい・・・)

で、例の 0x403d0 には何が書かれるかというと、

$ LANG=C arm-linux-objdump -RC qinstall.so | less
qinstall.so:     file format elf32-littlearm

DYNAMIC RELOCATION RECORDS
OFFSET   TYPE              VALUE
00032f5c R_ARM_ABS32       QTextStream::width(int)
    :
000403cc R_ARM_JUMP_SLOT   QCString::QCString(char const *)
000403d0 R_ARM_JUMP_SLOT   QString::fromLatin1(char const *, int)
000403d4 R_ARM_JUMP_SLOT   QFile::exists(void) const
   :

QString::fromLatin1 のようだ。リンカがアドレス解決すると、0x403d0 に QString::fromLatin1 のアドレスが書き込まれる。
つまり、まとめると、bl  0x1142c は QString::fromLatin1 をコールしていたというわけだ。

といった感じで、残りのコール先も調べると、以下の様にになった。

   26d4c:       ebffa9b6        bl      0x1142c		; 0x403D0 QString::fromLatin1(char const *, int)
26d60: ebffaa05 bl 0x1157c ; 0x40424 QString::find(QString const &, int, bool) const
26d9c: ebffa7f2 bl 0x10d6c ; 0x40220 QStringData::deleteSelf(void)
26db8: ebffa9e3 bl 0x1154c ; 0x40418 QString::operator=(char const *)
26e50: ebffa6c1 bl 0x1095c ; 0x4011C QString::latin1(void) const
26e58: ebffa617 bl 0x106bc ; 0x40074 statfs

お、ちゃんと statfs を呼んでいるようだ。

qinstall.so 内で他に statfs を呼んでないかを調べてみる。

$ LANG=C arm-linux-objdump -d qinstall.so | grep 0x106bc
arm-linux-objdump: qinstall.so: no symbols
   26e58:    ebffa617     bl    0x106bc

うん。getAvailableSize 関数でしか呼んでないみたい。この関数でビンゴだ。

(まだまだ続く・・・)