读《Professional Assembly Language》之lc消失之迷

上文里说到了，在x86-64的机器上，通过对as命令加入–32 参数，并在 ld 命令里加入-melf_i386参数，即可编译并链接成32-bit的cpuid。关于这两个参数的说明，可以参看man手册。

同样是在第四章节，链接c库函数，作者提供了另一个版本的cpuid，这次链接过程出现了新问题，可不是简单加入个参数就能解决的。是什么问题呢？如下：
$ as -gstabs --32 -o cpuid2.o cpuid2.s
$ ld -melf_i386 -dynamic-linker /lib/ld-linux.so.2 -o cpuid2 -lc cpuid2.o
ld: skipping incompatible /usr/lib/libc.so when searching for -lc
ld: skipping incompatible /usr/lib/libc.a when searching for -lc
ld: cannot find -lc

读《Professional Assembly Language》之EAX消失之迷

CPUID的例子出现第四章，A Sample Assembly Language Program，也是全书第一个完整的代码示例，结构简单，编译和链接均正常，执行结果也符合预期。

但是，在接下来的过程中出现了问题，DEBUG是日常工作的一部分，我把它视作是显微镜。使用GDB调试，每次查看通用寄存器都看不到想要的结果，而会被告知：Value can’t be converted to integer.。

同时，如果使用 info registers，则根本找不到任何eax等寄存器的踪影，取而代之的是rax等一类新面孔，如图所示。

AWS Free Usage Tier 的“陷阱”

话说：占小便宜吃大亏，从来都是笑别人爱占小便宜，没想到自己这次AWS Free Usage Tier成了“偷鸡不成蚀把米”。

此事从一个月前开始，因为做Hadoop的试验，需要找一个Linux环境，先后考虑了两种方案，首先是家里的Debian，但因为不能随时登录而作罢；然后又考虑unix-center.net，但是受限于每个用户最多分配100Mb内存，也只好放弃。最后从CPyUG华蟒用户组的邮件里，看到有人讨论AWS Free Usage Tier，虽然很早就注册AWS了，但因为收费的原因，一直就没用过，这次算是发现了这一“天上掉馅饼”的好事。于是就有了前文Amazon EC2与三个小问题。

Amazon EC2与三个小问题

自从Amazon推出AWS Free Usage Tier以来，越来越多的人开始尝试云计算。出售和购买看不见、摸不着的计算能力，成为了一种新的商业模式，并且这股势头正在迅速抬升。

网络中有很多的新手教程，比如我推荐一篇《Amazon AWS漫游指南》（能否访问视GFW情绪而定），因此我就不赘述了。这里，我仅从技术角度来回顾在初次接触AWS时遇到的一些问题，希望对一些新接触者有所帮助。

Android ProGuard: Please correct the above warnings first

编译与反编译，一对相辅相成的矛盾。反编译有时候会和不光彩的事情联系在一起，以致于编译者常常费劲心思，加大反编译的难度，比如采用混淆代码等方式。ProGuard正是这么一个工具：

The ProGuard tool shrinks, optimizes, and obfuscates your code by removing unused code and renaming classes, fields, and methods with semantically obscure name.