Alpine Linux Porting (一点五?)

持续卡关debug的一天。不过至少可以纪录一下今天弄出debug环境的笔记：
上篇提到seperated debug symbol gdb吃不进去的问题，而我们现在刚好在一个青黄不接的debug状态下，既没有完整的native环境、打造gdbserver要穿网路出来也很麻烦。此时比较适当的作法还是，我们必须想办法编出一个debug build、然後使用qemu linux-user mode来配合runtime error的剖析。

此时有两套作法，一套是必须在Alpine的world外重新打一套toolchain跟要debug的套件（白话说就是重建整个sysroot）；另一套是深入Alpine的abuild/aports建置系统作处置。因为目前并不明朗是哪个环节出错，为了避免引入太多变因，我的选择是现在走後者。

按照Alpine的APKBUILD reference有说，可以在options中指定nostrip的选项、并且可以指定 nodbg 来避免制作出seperated debug symbol套件。然而这两点我在测试apk与musl两个 aports套件时，其实遇到abuilds不听使唤的状况：出於未知的原因，musl依旧会被strip掉并且丢出去给 musl-dbg.apk、而apk则是没有预设可以作debug build的选项。於是我最後的作法，其实是有点暴力地善用反正我有docker在管理我的建置还硬 — — 直接退版到bootstraping musl前，在APKBUILD的configure阶段直接把所有subpackage干掉、并且强行补上-g3 -O0来建置。

在重新bootstrap出这一版debug build後，便可以成功地拿到一套有debug symbol的世界来作debug — — 很快地，我发现是所有 dynamic loading 程序，在musl的ldso启动时、尝试mapping shared object时、炸在帮对应的记忆体区段清零的一开头：

而为何libc-test没有压出这问题，原因是他的动态连结测试，只有在dlopen()的部份，这跟直接elf header插INTERP、kernel loadup直接解掉所有dynamic linked symbol时的code flow是不一样的。现在locate出这问题後，我可以非常快速地建立出最小化的测资，一个main.c、跟一个不做事的stub function的 foo.so去作link，然後开始debug user program，往後这部份的debug与测试也不需劳师动众 abuild 出来了。

下篇，将是开始debug这个dynlink的故事～