和Google Android Debugging Utilities

首先，我们需要一个含有调试信息的exe文件，一般这个文件存在于out/target/product/generic/obj/EXECUTABLES/yourexefile_intermediates/LINKED/libomstts目录下，这里以我们前面文章中生成的helloworld为例。

1. 下载Android Debugging Utilities

gdb and gdb-server (6.8)

2. 启动Android Emulator模拟器

$ emulator @1.5_R2

3. 把gdb和调试文件以及源代码放到模拟器上

$ adb push gdb /data/bin

$ adb push helloworld /data/bin

以helloworld为例，源代码要放在/data/bin/development/hello目录下。

有的文章说将以上文件放在/system/bin目录下，但后果是一旦关掉模拟器，这些的文件就消失了，下次又要重传~所以推荐放在/data/bin目录下。

4. 启动shell

$adb shell

如果提示文件系统不可写的话，执行：

＃mount -o remount

5. 因为Android文件系统没有/bin/sh, 所以这里有两种解决方法（推荐第二种方法）：

(1). 拷贝一个bash文件(点击下载)到/bin目录下：

#mkdir /bin

$adb push bash /bin

(2). 或者设置SHELL的路径：

#export SHELL=/system/bin/sh

6. 进入/data/bin目录，运行gdb，可以开始调试程序了

#cd /data/bin

#./gdb helloworld

——————————————-

Android编译环境提供了”showcommands”选项来显示编译命令行，我们可以通过打开这个选项来查看一些编译时的细节。当然，在这之前要把上一篇中的helloworld模块clean:

# make clean-helloworld

上面的“make clean-$(LOCAL_MODULE)”是Android编译环境提供的make clean的方式。

接下来使用showcommands选项重新编译helloworld:

从上面的命令行可以看到，Android编译环境所用的交叉编译工具链是prebuilt/linux-x86/toolchain/arm-eabi-4.2.1/bin/arm-eabi-gcc，-I和-L参数指定了所用的C库头文件和动态库文件路径分别是bionic/libc/include 和out/target/product/generic/obj/lib，其他还包括很多编译选项以及-D所定义的预编译宏。

我们可以利用上面的编译命令，稍加简化来手工编译helloworld程序。先手工删除上次编译得到的helloworld程序：

再用gcc编译，生成目标文件：

与Android.mk编译参数比较，上面主要减少了不必要的-I参数。

接下来生成可执行文件：

这里值得留意的是参数“-Wl,-dynamic-linker,/system/bin/linker”，它指定了Android专用的动态链接器/system/bin/linker，而不是通常所用的ld.so。

生成的可执行程序可用file和readelf命令来查看一下：

这是ARM格式的动态链接可执行文件，运行时需要libc.so和libm.so。“not stripped”表示它还没被STRIP。嵌入式系统中为节省空间通常将编译完成的可执行文件或动态库进行STRIP，即去掉其中多余的符号表信息。在前面“make helloworld showcommands”命令的最后我们也可以看到，Android编译环境中使用了out/host/linux-x86/bin/soslim工具进行STRIP。

有关Android Toolchain的其他一些内容可参考：Android Toolchain与Bionic Libc

———————————————————

Android 编译环境本身比较复杂，且不像普通的编译环境：只有顶层目录下才有Makefile文件，而其他的每个component都使用统一标准的 Android.mk. Android.mk文件本身是比较简单的，不过它并不是我们熟悉的Makefile，而是经过了Android自身编译系统的很多处理，因此要真正理清楚其中的联系还比较复杂，不过这种方式的好处在于，编写一个新的Android.mk来给Android增加一个新的Component会比较简单。编译Java程序可以直接采用Eclipse的集成环境来完成，这里就不重复了。我们主要针对C/C++来说明，下面通过一个小例子来说明，如何在Android 中增加一个C程序的Hello World：

1. 在$(YOUR_ANDROID)/development目录下创建hello目录，其中$(YOUR_ANDROID)指Android源代码所在的目录。

$ mkdir $(YOUR_ANDROID)/development/hello

2. 在$(YOUR_ANDROID)/development/hello/目录编写hello.c文件，hello.c的内容当然就是经典的HelloWorld程序：

int main()
{
printf("Hello World!\n");
return 0;
}

3.在$(YOUR_ANDROID)/development/hello/目录编写Android.mk文件。这是Android Makefile的标准命名，不要更改。Android.mk文件的格式和内容可以参考其他已有的Android.mk文件的写法，针对helloworld程序的Android.mk文件内容如下：

LOCAL_PATH:= $(call my-dir)
include $(CLEAR_VARS)

LOCAL_SRC_FILES:= \
hello.c

LOCAL_MODULE := helloworld
include $(BUILD_EXECUTABLE)

注意上面LOCAL_SRC_FILES用来指定源文件，LOCAL_MODULE指定要编译的模块的名字，下一步骤编译时就要用到。include $(BUILD_EXECUTABLE)表示要编译成一个可执行文件，如果想编译成动态库则可用BUILD_SHARED_LIBRARY，这些可以在$(YOUR_ANDROID)/build/core/config.mk查到。

4. 回到Android源代码顶层目录进行编译：

# cd $(YOUR_ANDROID) && make helloworld

注意make helloworld中的目标名helloworld就是上面Android.mk文件中由LOCAL_MODULE指定的模块名。编译结果如下：

target thumb C: helloworld <= development/hello/hello.c
target Executable: helloworld (out/target/product/generic/obj/EXECUTABLES/helloworld_intermediates/LINKED/helloworld)
target Non-prelinked: helloworld (out/target/product/generic/symbols/system/bin/helloworld)
target Strip: helloworld (out/target/product/generic/obj/EXECUTABLES/helloworld_intermediates/helloworld)
Install: out/target/product/generic/system/bin/helloworld

5．如上面的编译结果所示，编译后的可执行文件存放在out/target/product/generic/system/bin/helloworld，通过”adb push”将它传送到模拟器上，再通过”adb shell”登录到模拟器终端，就可以执行了

有的时候，在脑海中停顿了很久的“显而易见”的东西，其实根本上就是错误的。就拿下面的问题来看：

struct T
{
char ch;
int i ;
};

使用sizeof(T)，将得到什么样的答案呢？要是以前，想都不用想，在32位机中，int是4个字节，char是1个字节，所以T一共是5个字节。实践出真知，在VC6中测试了下，答案确实8个字节。哎，反正受伤的总是我，我已经有点麻木了，还是老老实实的接受吧！为什么答案和自己想象的有出入呢？这里将引入内存对齐这个概念。

许多实际的计算机系统对基本类型数据在内存中存放的位置有限制，它们会要求这些数据的首地址的值是某个数k(通常它为4或8)的倍数，这就是所谓的内存对齐，而这个k则被称为该数据类型的对齐模数(alignment modulus)。当一种类型S的对齐模数与另一种类型T的对齐模数的比值是大于1的整数，我们就称类型S的对齐要求比T强(严格)，而称T比S弱(宽松)。这种强制的要求一来简化了处理器与内存之间传输系统的设计，二来可以提升读取数据的速度。比如这么一种处理器，它每次读写内存的时候都从某个8倍数的地址开始，一次读出或写入8个字节的数据，假如软件能保证double类型的数据都从8倍数地址开始，那么读或写一个double类型数据就只需要一次内存操作。否则，我们就可能需要两次内存操作才能完成这个动作，因为数据或许恰好横跨在两个符合对齐要求的8字节内存块上。某些处理器在数据不满足对齐要求的情况下可能会出错，但是Intel的IA32架构的处理器则不管数据是否对齐都能正确工作。不过Intel奉劝大家，如果想提升性能，那么所有的程序数据都应该尽可能地对齐。

ANSI C标准中并没有规定，相邻声明的变量在内存中一定要相邻。为了程序的高效性，内存对齐问题由编译器自行灵活处理，这样导致相邻的变量之间可能会有一些填充字节。对于基本数据类型(int char)，他们占用的内存空间在一个确定硬件系统下有个确定的值，所以，接下来我们只是考虑结构体成员内存分配情况。

Win32平台下的微软C编译器(cl.exe for 80×86)的对齐策略：

1) 结构体变量的首地址能够被其最宽基本类型成员的大小所整除；

备注：编译器在给结构体开辟空间时，首先找到结构体中最宽的基本数据类型，然后寻找内存地址能被该基本数据类型所整除的位置，作为结构体的首地址。将这个最宽的基本数据类型的大小作为上面介绍的对齐模数。

2) 结构体每个成员相对于结构体首地址的偏移量（offset）都是成员大小的整数倍，如有需要编译器会在成员之间加上填充字节（internal adding）；

备注:为结构体的一个成员开辟空间之前，编译器首先检查预开辟空间的首地址相对于结构体首地址的偏移是否是本成员的整数倍，若是，则存放本成员，反之，则在本成员和上一个成员之间填充一定的字节，以达到整数倍的要求，也就是将预开辟空间的首地址后移几个字节。

3) 结构体的总大小为结构体最宽基本类型成员大小的整数倍，如有需要，编译器会在最末一个成员之后加上填充字节（trailing padding）。

备注：结构体总大小是包括填充字节，最后一个成员满足上面两条以外，还必须满足第三条，否则就必须在最后填充几个字节以达到本条要求。

根据以上准则，在windows下，使用VC编译器，sizeof(T)的大小为1(char) + 3(填充) + 4(int) =8个字节。

而在GNU GCC编译器中，遵循的准则有些区别，对齐模数不是像上面所述的那样，根据最宽的基本数据类型来定。在GCC中，对齐模数的准则是：对齐模数最大只能是4，也就是说，即使结构体中有double类型，对齐模数还是4，所以对齐模数只能是1，2，4。而且在上述的三条中，第2条里，offset必须是成员大小的整数倍，如果这个成员大小小于等于4则按照上述准则进行，但是如果大于4了，则结构体每个成员相对于结构体首地址的偏移量（offset）只能按照是4的整数倍来进行判断是否添加填充。

看如下例子：

struct T
{
char ch;
double d ;
};

那么在GCC下，sizeof(T)应该等于12个字节。

如果结构体中含有位域(bit-field)，那么VC中准则又要有所更改：

1) 如果相邻位域字段的类型相同，且其位宽之和小于类型的sizeof大小，则后面的字段将紧邻前一个字段存储，直到不能容纳为止；

2) 如果相邻位域字段的类型相同，但其位宽之和大于类型的sizeof大小，则后面的字段将从新的存储单元开始，其偏移量为其类型大小的整数倍；

3) 如果相邻的位域字段的类型不同，则各编译器的具体实现有差异，VC6采取不压缩方式（不同位域字段存放在不同的位域类型字节中），Dev-C++和GCC都采取压缩方式；

备注：当两字段类型不一样的时候，对于不压缩方式，例如：

struct N
{
char c:2;
int i:4;
};

依然要满足不含位域结构体内存对齐准则第2条，i成员相对于结构体首地址的偏移应该是4的整数倍，所以c成员后要填充3个字节，然后再开辟4个字节的空间作为int型，其中4位用来存放i，所以上面结构体在VC中所占空间为8个字节；而对于采用压缩方式的编译器来说，遵循不含位域结构体内存对齐准则第2条，不同的是，如果填充的3个字节能容纳后面成员的位，则压缩到填充字节中，不能容纳，则要单独开辟空间，所以上面结构体N在GCC或者Dev-C++中所占空间应该是4个字节。

4) 如果位域字段之间穿插着非位域字段，则不进行压缩；

备注：

结构体

typedef struct
{
char c:2;
double i;
int c2:4;
}N3;

在GCC下占据的空间为16字节，在VC下占据的空间应该是24个字节。

5) 整个结构体的总大小为最宽基本类型成员大小的整数倍。

ps:

对齐模数的选择只能是根据基本数据类型，所以对于结构体中嵌套结构体，只能考虑其拆分的基本数据类型。而对于对齐准则中的第2条，确是要将整个结构体看成是一个成员，成员大小按照该结构体根据对齐准则判断所得的大小。

类对象在内存中存放的方式和结构体类似，这里就不再说明。需要指出的是，类对象的大小只是包括类中非静态成员变量所占的空间，如果有虚函数，那么再另外增加一个指针所占的空间即可。

from：http://www.ksarea.com/articles/20071004_sizeof-struct-memory.html

(二)

在ARM 下要使结构体按指定字节对齐，可行的方法有两种：

1.在makefile里增加-fpack-struct选项，这样的话对所有的结构按一字节对齐。

不得不说，确实有那么些质量较差的程序可能需要你部分自然对齐，部分一字节对齐，此时

2. typedef struct pack{
}__attribute__((packed))

可利用__attribute__属性

当然最后的方式，还是自己去看ARM体系结构与gcc编译选项了。

用法：

1．可以定义 const 常量

2．const可以修饰函数的参数、返回值，甚至函数的定义体。被const修饰的东西都受到强制保护，可以预防意外的变动，能提高程序的健壮性。

const意味着”只读”。区别如下代码的功能非常重要。

const int a;
int const a;
const int *a;
int * const a;
int const * a const;

前两个作用是一样的，a是一个常整型数。

第三个意味着a是一个指向常整型数的指针（也就是，整型数是不可修改的，但指针可以）。

第四个意思是a是一个指向整型数的常指针（也就是，指针指向的整型数是可以修改的，但指针是不可修改的）。

最后一个意味着a是一个指向常整型数的常指针（也就是，指针指向的整型数是不可修改的，同时指针也是不可修改的）。

关键字const的作用是为给读你代码的人传达非常有用的信息。例如，在函数的形参前添加const关键字意味着这个参数在函数体内不会被修改，属于”输入参数”。在有多个形参的时候，函数的调用者可以凭借参数前是否有const关键字，清晰的辨别哪些是输入参数，哪些是可能的输出参数。

合理地使用关键字const可以使编译器很自然地保护那些不希望被改变的参数，防止其被无意的代码修改，这样可以减少bug的出现。

const在C++语言中则包含了更丰富的含义，而在C语言中仅意味着：”只能读的普通变量”，可以称其为”不能改变的变量”（这个说法似乎很拗口，但却最准确的表达了C语言中const的本质），在编译阶段需要的常数仍然只能以#define宏定义！故在C语言中如下程序是非法的：

const int SIZE = 10;
char a[SIZE]; /* 非法：编译阶段不能用到变量 */

以下是工作中的使用const例子：

const unsigned char * pbyData;
unsigned char const DayPerMonth[12] = { 31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31 } ;
extern void dp_write_dsp_block ( const word *bp, word len );
const unsigned short InterMapSparseIdx[];

—————————————————————

关键字static：

关键字static是一个存储类说明符，同extern，typedef一样，因此他们不能同时使用。

定义：说明符static将声明的对象说明为静态存储类

在C语言中，关键字static有三个明显的作用：

1．static用于声明内部变量

在函数体内，一个被声明为static的变量在这一函数被调用过程中仅分配一次内存，且函数结束后其不会被销毁。

e.g.：

输出为：
2
3
4
5
6

2．static用于声明外部变量

在模块内（但在函数体外），一个被声明为static的变量可以被模块内所有函数访问，但不能被模块外其它函数访问。它是一个本地的全局变量（最常见的用法）。

3．static用于声明函数

在模块内，一个被声明为static的函数只可被这一模块内的其它函数调用。那就是，这个函数被限制在声明它的模块的本地范围内使用。

typedef struct tagNode
{
char *pItem;
struct tagNode *pNext;
}*pNode;

正文：

1. 基本解释

typedef为C语言的关键字，作用是为一种数据类型定义一个新名字。这里的数据类型包括内部数据类型（int,char等）和自定义的数据类型（struct等）。

在编程中使用typedef目的一般有两个，一个是给变量一个易记且意义明确的新名字，另一个是简化一些比较复杂的类型声明。

至于typedef有什么微妙之处，请你接着看下面对几个问题的具体阐述。

2. typedef 结构的问题

当用下面的代码定义一个结构时，编译器报了一个错误，为什么呢？莫非C语言不允许在结构中包含指向它自己的指针吗？请你先猜想一下，然后看下文说明：

typedef struct tagNode
{
char *pItem;
struct tagNode *pNext;
}*pNode;

答案与分析：

1、typedef的最简单使用

typedef long byte_4;

给已知数据类型long起个新名字，叫byte_4。

2、 typedef与结构结合使用

typedef struct tagMyStruct
{
int iNum;
long lLength;
} MyStruct;

这语句实际上完成两个操作：

1) 定义一个新的结构类型

typedef struct tagMyStruct
{
int iNum;
long lLength;
};

分析：tagMyStruct称为“tag”，即“标签”，实际上是一个临时名字，struct 关键字和tagMyStruct一起，构成了这个结构类型，不论是否有typedef，这个结构都存在。

我们可以用struct tagMyStruct varName来定义变量，但要注意，使用tagMyStruct varName来定义变量是不对的，因为struct 和tagMyStruct合在一起才能表示一个结构类型。

2) typedef为这个新的结构起了一个名字，叫MyStruct。

typedef struct tagMyStruct MyStruct;

因此，MyStruct实际上相当于struct tagMyStruct，我们可以使用MyStruct varName来定义变量。

答案与分析

C语言当然允许在结构中包含指向它自己的指针，我们可以在建立链表等数据结构的实现上看到无数这样的例子，上述代码的根本问题在于typedef的应用。

根据我们上面的阐述可以知道：新结构建立的过程中遇到了pNext域的声明，类型是pNode，要知道pNode表示的是类型的新名字，那么在类型本身还没有建立完成的时候，这个类型的新名字也还不存在，也就是说这个时候编译器根本不认识pNode。

解决这个问题的方法有多种：

1)、

typedef struct tagNode
{
char *pItem;
struct tagNode *pNext;
}*pNode;

2)、

typedef struct tagNode *pNode
struct tagNode
{
char *pItem;
pNode *pNext;
};

注意：在这个例子中，你用typedef给一个还未完全声明的类型起新名字。C语言编译器支持这种做法。

3)、规范做法：

struct tagNode
{
char *pItem;
pNode *pNext;
};
typedef struct tagNode *pNode;

文章出处：http://www.diybl.com/course/3_program/c++/cppjs/2008828/138362.html