表示方式 section:disp(base,index,scale)

   变址寻址  AT&T: _variable(%eax)  Intel: [eax + _variable]

       For BSD formats and when the stat keyword is used, additional
       characters may be displayed:
       <    high-priority (not nice to other users)
       N    low-priority (nice to other users)
       L    has pages locked into memory (for real-time and custom IO)
       s    is a session leader
       l    is multi-threaded (using CLONE_THREAD, like NPTL pthreads do)
       +    is in the foreground process group

   对于提供了MMU（存储管理器，辅助操作系统进行内存管理，提供虚实地址转换等硬件支持）的处理器而言，Linux提供了复杂的存储管理系统，使得进程所能访问的内存达到4GB。

　　进程的4GB内存空间被人为的分为两个部分--用户空间与内核空间。用户空间地址分布从0到3GB(PAGE_OFFSET，在0x86中它等于0xC0000000)，3GB到4GB为内核空间。

　　内核空间中，从3G到vmalloc_start这段地址是物理内存映射区域（该区域中包含了内核镜像、物理页框表mem_map等等），比如我们使用的 VMware虚拟系统内存是160M，那么3G～3G+160M这片内存就应该映射物理内存。在物理内存映射区之后，就是vmalloc区域。对于 160M的系统而言，vmalloc_start位置应在3G+160M附近（在物理内存映射区与vmalloc_start期间还存在一个8M的gap 来防止跃界），vmalloc_end的位置接近4G(最后位置系统会保留一片128k大小的区域用于专用页面映射)

　　　　　kmalloc和get_free_page申请的内存位于物理内存映射区域，而且在物理上也是连续的，它们与真实的物理地址只有一个固定的偏移，因此存在较简单的转换关系，virt_to_phys()可以实现内核虚拟地址转化为物理地址：
   #define __pa(x) ((unsigned long)(x)-PAGE_OFFSET)
   extern inline unsigned long virt_to_phys(volatile void * address)
   {
       　return __pa(address);
   }
上面转换过程是将虚拟地址减去3G（PAGE_OFFSET=0XC000000）。

与之对应的函数为phys_to_virt()，将内核物理地址转化为虚拟地址：
   #define __va(x) ((void *)((unsigned long)(x)+PAGE_OFFSET))
   extern inline void * phys_to_virt(unsigned long address)
   {
       　return __va(address);
   }
virt_to_phys()和phys_to_virt()都定义在include\asm-i386\io.h中。

-------------------------------------------------------------------------------------
1、kmalloc() 分配连续的物理地址，用于小内存分配。

　　2、__get_free_page() 分配连续的物理地址，用于整页分配。

　　至于为什么说以上函数分配的是连续的物理地址和返回的到底是物理地址还是虚拟地址，下面的记录会做出解释。

　　kmalloc() 函数本身是基于 slab 实现的。slab 是为分配小内存提供的一种高效机制。但 slab 这种分配机制又不是独立的，它本身也是在页分配器的基础上来划分更细粒度的内存供调用者使用。也就是说系统先用页分配器分配以页为最小单位的连续物理地址，然后 kmalloc() 再在这上面根据调用者的需要进行切分。

　　关于以上论述，我们可以查看 kmalloc() 的实现，kmalloc()函数的实现是在 __do_kmalloc() 中，可以看到在 __do_kmalloc()代码里最终调用了 __cache_alloc() 来分配一个 slab，其实

　　kmem_cache_alloc() 等函数的实现也是调用了这个函数来分配新的 slab。我们按照 __cache_alloc()函数的调用路径一直跟踪下去会发现在 cache_grow() 函数中使用了 kmem_getpages()函数来分配一个物理页面，kmem_getpages() 函数中调用的alloc_pages_node() 最终是使用 __alloc_pages() 来返回一个struct page 结构，而这个结构正是系统用来描述物理页面的。这样也就证实了上面所说的，slab 是在物理页面基础上实现的。kmalloc() 分配的是物理地址。

　　__get_free_page() 是页面分配器提供给调用者的最底层的内存分配函数。它分配连续的物理内存。__get_free_page() 函数本身是基于 buddy 实现的。在使用 buddy 实现的物理内存管理中最小分配粒度是以页为单位的。关于以上论述，我们可以查看__get_free_page()的实现，可以看到__get_free_page()函数只是一个非常简单的封状，它的整个函数实现就是无条件的调用 __alloc_pages() 函数来分配物理内存，上面记录 kmalloc()实现时也提到过是在调用 __alloc_pages() 函数来分配物理页面的前提下进行的 slab 管理。那么这个函数是如何分配到物理页面又是在什么区域中进行分配的？回答这个问题只能看下相关的实现。可以看到在 __alloc_pages() 函数中，多次尝试调用get_page_from_freelist() 函数从 zonelist 中取得相关 zone，并从其中返回一个可用的 struct page 页面（这里的有些调用分支是因为标志不同）。至此，可以知道一个物理页面的分配是从 zonelist（一个 zone 的结构数组）中的 zone 返回的。那么 zonelist/zone 是如何与物理页面关联，又是如何初始化的呢？继续来看 free_area_init_nodes() 函数，此函数在系统初始化时由 zone_sizes_init() 函数间接调用的，zone_sizes_init()函数填充了三个区域：ZONE_DMA，ZONE_NORMAL，ZONE_HIGHMEM。并把他们作为参数调用 free_area_init_nodes()，在这个函数中会分配一个 pglist_data 结构，此结构中包含了 zonelist/zone结构和一个 struct page 的物理页结构，在函数最后用此结构作为参数调用了 free_area_init_node() 函数，在这个函数中首先使用 calculate_node_totalpages() 函数标记 pglist_data 相关区域，然后调用 alloc_node_mem_map() 函数初始化 pglist_data结构中的 struct page 物理页。最后使用 free_area_init_core()函数关联 pglist_data 与 zonelist。现在通以上分析已经明确了__get_free_page() 函数分配物理内存的流程。但这里又引出了几个新问题，那就是此函数分配的物理页面是如何映射的？映射到了什么位置？到这里不得不去看下与 VMM 相关的引导代码。

　　在看 VMM 相关的引导代码前，先来看一下 virt_to_phys() 与phys_to_virt 这两个函数。顾名思义，即是虚拟地址到物理地址和物理地址到虚拟地址的转换。函数实现十分简单，前者调用了__pa( address ) 转换虚拟地址到物理地址，后者调用 __va(addrress ) 将物理地址转换为虚拟地址。再看下 __pa __va 这两个宏到底做了什么。

　　#define __pa(x) ((unsigned long)(x)-PAGE_OFFSET)
　　#define __va(x) ((void *)((unsigned long)(x)+PAGE_OFFSET))

　　通过上面可以看到仅仅是把地址加上或减去 PAGE_OFFSET，而PAGE_OFFSET 在 x86 下定义为 0xC0000000。这里又引出了疑问，在 linux 下写过 driver 的人都知道，在使用 kmalloc() 与

　　__get_free_page() 分配完物理地址后，如果想得到正确的物理地址需要使用 virt_to_phys() 进行转换。那么为什么要有这一步呢？我们不分配的不就是物理地址么？怎么分配完成还需要转换？如果返回的是虚拟地址，那么根据如上对 virt_to_phys() 的分析，为什么仅仅对 PAGE_OFFSET 操作就能实现地址转换呢？虚拟地址与物理地址之间的转换不需要查页表么？代着以上诸多疑问来看 VMM 相关的引导代码。

　　直接从 start_kernel() 内核引导部分来查找 VMM 相关内容。可以看到第一个应该关注的函数是 setup_arch()，在这个函数当中使用paging_init() 函数来初始化和映射硬件页表（在初始化前已有 8M内存被映射，在这里不做记录），而 paging_init() 则是调用的pagetable_init() 来完成内核物理地址的映射以及相关内存的初始化。在 pagetable_init() 函数中，首先是一些 PAE/PSE/PGE 相关判断与设置，然后使用 kernel_physical_mapping_init() 函数来实现内核物理内存的映射。在这个函数中可以很清楚的看到，pgd_idx 是以PAGE_OFFSET 为启始地址进行映射的，也就是说循环初始化所有物理地址是以 PAGE_OFFSET 为起点的。继续观察我们可以看到在 PMD 被初始化后，所有地址计算均是以 PAGE_OFFSET 作为标记来递增的。分析到这里已经很明显的可以看出，物理地址被映射到以 PAGE_OFFSET 开始的虚拟地址空间。这样以上所有疑问就都有了答案。kmalloc() 与__get_free_page() 所分配的物理页面被映射到了 PAGE_OFFSET 开始的虚拟地址，也就是说实际物理地址与虚拟地址有一组一一对应的关系，

　　正是因为有了这种映射关系，对内核以 PAGE_OFFSET 启始的虚拟地址的分配也就是对物理地址的分配（当然这有一定的范围，应该在 PAGE_OFFSET与 VMALLOC_START 之间，后者为 vmalloc() 函数分配内存的启始地址）。这也就解释了为什么 virt_to_phys() 与 phys_to_virt() 函数的实现仅仅是加/减 PAGE_OFFSET 即可在虚拟地址与物理地址之间转换，正是因为了有了这种映射，且固定不变，所以才不用去查页表进行转换。这也同样回答了开始的问题，即 kmalloc() / __get_free_page() 分配的是物理地址，而返回的则是虚拟地址（虽然这听上去有些别扭）。正是因为有了这种映射关系，所以需要将它们的返回地址减去 PAGE_OFFSET 才可以得到真正的物理地址。

另一篇更容易理解的：

kmalloc, vmalloc分配的内存结构 zz
2008-01-20 16:05
进程空间：| <-用户空间-> | <-内核空间-> |
内核空间：| <-物理内存映射区-> | <-vmalloc区域-> |

==============原文================================

   对于提供了MMU（存储管理器，辅助操作系统进行内存管理，提供虚实地址转换等硬件支持）的处理器而言，Linux提供了复杂的存储管理系统，使得进程所能访问的内存达到4GB。

进程的4GB内存空间被人为的分为两个部分--用户空间与内核空间。用户空间地址分布从0到3GB(PAGE_OFFSET，在0x86中它等于0xC0000000)，3GB到4GB为内核空间。

内核空间中，从3G到vmalloc_start这段地址是物理内存映射区域（该区域中包含了内核镜像、物理页框表mem_map等等），比如我们使用 的 VMware虚拟系统内存是160M，那么3G～3G+160M这片内存就应该映射物理内存。在物理内存映射区之后，就是vmalloc区域。对于 160M的系统而言，vmalloc_start位置应在3G+160M附近（在物理内存映射区与vmalloc_start期间还存在一个8M的gap 来防止跃界），vmalloc_end的位置接近4G(最后位置系统会保留一片128k大小的区域用于专用页面映射)

kmalloc和get_free_page申请的内存位于物理内存映射区域，而且在物理上也是连续的，它们与真实的物理地址只有一个固定的偏移，因此存在较简单的转换关系，virt_to_phys()可以实现内核虚拟地址转化为物理地址：
   #define __pa(x) ((unsigned long)(x)-PAGE_OFFSET)
   extern inline unsigned long virt_to_phys(volatile void * address)
   {
       　return __pa(address);
   }
上面转换过程是将虚拟地址减去3G（PAGE_OFFSET=0XC000000）。

与之对应的函数为phys_to_virt()，将内核物理地址转化为虚拟地址：
   #define __va(x) ((void *)((unsigned long)(x)+PAGE_OFFSET))
   extern inline void * phys_to_virt(unsigned long address)
   {
       　return __va(address);
   }
virt_to_phys()和phys_to_virt()都定义在include\asm-i386\io.h中。

而vmalloc申请的内存则位于vmalloc_start～vmalloc_end之间，与物理地址没有简单的转换关系，虽然在逻辑上它们也是连续的，但是在物理上它们不要求连续。

我们用下面的程序来演示kmalloc、get_free_page和vmalloc的区别：
#include <linux/module.h>
#include <linux/slab.h>
#include <linux/vmalloc.h>
MODULE_LICENSE("GPL");
unsigned char *pagemem;
unsigned char *kmallocmem;
unsigned char *vmallocmem;

int __init mem_module_init(void)
{
//最好每次内存申请都检查申请是否成功
//下面这段仅仅作为演示的代码没有检查
pagemem = (unsigned char*)get_free_page(0);
printk("<1>pagemem addr=%x", pagemem);

kmallocmem = (unsigned char*)kmalloc(100, 0);
printk("<1>kmallocmem addr=%x", kmallocmem);

vmallocmem = (unsigned char*)vmalloc(1000000);
printk("<1>vmallocmem addr=%x", vmallocmem);

return 0;
}

void __exit mem_module_exit(void)
{
free_page(pagemem);
kfree(kmallocmem);
vfree(vmallocmem);
}

module_init(mem_module_init);
module_exit(mem_module_exit);

我们的系统上有160MB的内存空间，运行一次上述程序，发现pagemem的地址在0xc7997000（约3G+121M）、kmallocmem 地址在0xc9bc1380（约3G+155M）、vmallocmem的地址在0xcabeb000（约3G+171M）处，符合前文所述的内存布局。

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/sandflee/archive/2009/07/28/4388322.aspx

        POSIX是Portable Operating System Interface of Unix的缩写。由IEEE（Institute of Electrical and Electronic Engineering）开发，由ANSI和ISO标准化。
        POSIX的诞生和Unix的发展是密不可分的，Unix于70年代诞生于Bell lab，并于80年代向美各大高校分发V7版的源码以做研究。UC Berkeley在V7的基础上开发了BSD Unix。后来很多商业厂家意识到Unix的价值也纷纷以Bell Lab的System V或BSD为基础来开发自己的Unix，较著名的有Sun OS，AIX，VMS。由于各厂家对Unix的开发各自为政，造成了Unix的版本相当混乱，给软件的可移植性带来很大困难，对Unix的发展极为不利。为结束这种局面，IEEE开发了POSIX，POSIX在源代码级别上定义了一组最小的Unix(类Unix)操作系统接口。
        POSIX 表示可移植操作系统接口（Portable Operating System Interface ，缩写为 POSIX 是为了读音更像 UNIX）。电气和电子工程师协会（Institute of Electrical and Electronics Engineers，IEEE）最初开发 POSIX 标准，是为了提高 UNIX 环境下应用程序的可移植性。然而，POSIX 并不局限于 UNIX。许多其它的操作系统，例如 DEC OpenVMS 和 Microsoft Windows NT，都支持 POSIX 标准，尤其是 IEEE Std. 1003.1-1990（1995 年修订）或 POSIX.1，POSIX.1 提供了源代码级别的 C 语言应用编程接口（API）给操作系统的服务程序，例如读写文件。POSIX.1 已经被国际标准化组织（International Standards Organization，ISO）所接受，被命名为 ISO/IEC 9945-1:1990 标准。
        POSIX 现在已经发展成为一个非常庞大的标准族，某些部分正处在开发过程中。表 1-1 给出了 POSIX 标准的几个重要组成部分。POSIX 与 IEEE 1003 和 2003 家族的标准是可互换的。除 1003.1 之外，1003 和 2003 家族也包括在表中。

表1：标准的重要组成部分
1003.0
管理 POSIX 开放式系统环境（OSE）。IEEE 在 1995 年通过了这项标准。 ISO 的版本是 ISO/IEC 14252:1996。
1003.1
被广泛接受、用于源代码级别的可移植性标准。1003.1 提供一个操作系统的 C 语言应用编程接口（API）。IEEE 和 ISO 已经在 1990 年通过了这个标准，IEEE 在 1995 年重新修订了该标准。
1003.1b
一个用于实时编程的标准（以前的 P1003.4 或 POSIX.4）。这个标准在 1993 年被 IEEE 通过，被合并进 ISO/IEC 9945-1。
1003.1c
一个用于线程（在一个程序中当前被执行的代码段）的标准。以前是 P1993.4 或 POSIX.4 的一部分，这个标准已经在 1995 年被 IEEE 通过，归入 ISO/IEC 9945-1:1996。
1003.1g
一个关于协议独立接口的标准，该接口可以使一个应用程序通过网络与另一个应用程序通讯。 1996 年，IEEE 通过了这个标准。
1003.2
一个应用于 shell 和 工具软件的标准，它们分别是操作系统所必须提供的命令处理器和工具程序。 1992 年 IEEE 通过了这个标准。ISO 也已经通过了这个标准（ISO/IEC 9945-2:1993）。
1003.2d
改进的 1003.2 标准。
1003.5
一个相当于 1003.1 的 Ada 语言的 API。在 1992 年，IEEE 通过了这个标准。并在 1997 年对其进行了修订。ISO 也通过了该标准。
1003.5b
一个相当于 1003.1b（实时扩展）的 Ada 语言的 API。IEEE 和 ISO 都已经通过了这个标准。ISO 的标准是 ISO/IEC 14519:1999。
1003.5c
一个相当于 1003.1q（协议独立接口）的 Ada 语言的 API。在 1998 年， IEEE 通过了这个标准。ISO 也通过了这个标准。
1003.9
一个相当于 1003.1 的 FORTRAN 语言的 API。在 1992 年，IEEE 通过了这个标准，并于 1997 年对其再次确认。ISO 也已经通过了这个标准。
1003.10
一个应用于超级计算应用环境框架（Application Environment Profile，AEP）的标准。在 1995 年，IEEE 通过了这个标准。
1003.13
一个关于应用环境框架的标准，主要针对使用 POSIX 接口的实时应用程序。在 1998 年，IEEE 通过了这个标准。
1003.22
一个针对 POSIX 的关于安全性框架的指南。
1003.23
一个针对用户组织的指南，主要是为了指导用户开发和使用支持操作需求的开放式系统环境（OSE）框架
2003
针对指定和使用是否符合 POSIX 标准的测试方法，有关其定义、一般需求和指导方针的一个标准。在 1997 年，IEEE 通过了这个标准。
2003.1
这个标准规定了针对 1003.1 的 POSIX 测试方法的提供商要提供的一些条件。在 1992 年，IEEE 通过了这个标准。
2003.2
一个定义了被用来检查与 IEEE 1003.2（shell 和 工具 API）是否符合的测试方法的标准。在 1996 年，IEEE 通过了这个标准。

       除了 1003 和 2003 家族以外，还有几个其它的 IEEE 标准，例如 1224 和 1228，它们也提供开发可移植应用程序的 API。要想得到关于 IEEE 标准的最新信息，可以访问 IEEE 标准的主页，网址是 http://standards.ieee.org/。有关 POSIX 标准的概述信息，请访问 Web 站点 http://standards.ieee.org/reading/ieee/stad_public/description/posix/。

2. Liniux下的线程编程

        Linux系统下的多线程遵循POSIX线程接口，称为pthread。从上面的描述不难知道，POSIX线程接口是POSIX众多标准中的一个（POSIX 1003.1-2001）。

        编写Linux下的多线程程序，需要使用头文件pthread.h，连接时需要使用库libpthread.a。顺便说一下，Linux下pthread的实现是通过系统调用 clone() 来实现的。clone() 是Linux所特有的系统调用，它的使用方式类似fork，关于 clone() 的详细情况，有兴趣的读者可以去查看有关文档说明。

下面是一个 POSIX 线程的简单示例程序(thread1.c)：

#include <pthread.h>
#include <stdlib.h>
#include <unistd.h>
 void *thread_function(void *arg) ...{
  int i;
  for ( i=0; i<20; i++) ...{
    printf("Thread says hi! ");
    sleep(1);
  }
  return NULL;
}
int main(void) ...{
  pthread_t mythread;
  
  if ( pthread_create( &mythread, NULL, thread_function, NULL) ) ...{
    printf("error creating thread.");
    abort();
  }
  if ( pthread_join ( mythread, NULL ) ) ...{
    printf("error joining thread.");
    abort();
  }
  exit(0);
}

 要编译这个程序，只需先将程序存为 thread1.c，然后输入：

运行则输入：

3. Windows下POSIX线程编程

       Windows本身没有提供对POSIX的支持。但有一个叫 POSIX Threads for Win32 的开源项目给出了一个功能比较完善的Windows下pthreads API的实现。目前的最新版本是Pthreads-w32 release 2.8.0 (2006-12-22)。

       我没有测试过这个最新版本，这里只给出2.7.0版的链接：ftp://sources.redhat.com/pub/pthreads-win32/pthreads-w32-2-7-0-release.exe。

       关于该开源项目的详细介绍见：http://sources.redhat.com/pthreads-win32/。

3.1 简单使用

       上面的exe文件是一个自解压文件，解压后，Pre-built.2目录中有编译所需要的头文件（include子目录）和库文件（lib子目录）。

       一个简单的测试程序(main.cpp)：

#include <stdio.h>
#include <pthread.h>
#include <assert.h>

void* Function_t(void* Param)
...{
    printf("I am a thread!  ");
    pthread_t myid = pthread_self();
    printf("thread ID=%d ", myid);
    return NULL;
}

int main()
...{
    pthread_t pid;
    pthread_attr_t attr;
    pthread_attr_init(&attr);
    pthread_attr_setscope(&attr, PTHREAD_SCOPE_PROCESS);
    pthread_attr_setdetachstate(&attr, PTHREAD_CREATE_DETACHED);
    pthread_create(&pid, &attr, Function_t, NULL);
    printf("======================================== ");
    getchar();
    pthread_attr_destroy(&attr);
    return 1;
} 

使用 cl.exe 编译（不熟悉 cl.exe 的请参考：http://blog.csdn.net/liuyongjin1984/archive/2008/01/07/2029405.aspx 或者参见下面3.2部分）：

》rem cl.bat

》cl.exe main.cpp  /c  /I"c:pthreads-w32-2-7-0-releasePre-built.2include"

》link.exe  /out:main_cl.exe  main.obj  /LIBPATH:"c:pthreads-w32-2-7-0-releasePre-built.2lib"   pthreadVC2.lib

 3.2 使用VC++ 6.0或Visual Studio 2005来运行上面的程序

关键有两点：

1. 是将头文件（include子目录）和库文件（lib子目录）中的内容添加到VC++ 6.0或Visual Studio 2005开发环境对应的include和lib目录下。

具体来说（以添加include目录为例，添加lib目录类似）：

图1：VC++ 6.0（添加include目录：工具--》选项--》目录）

图2：Visual Studio 2005(添加include目录：tools--》options)

2. 指定link时要连接的库的名称（pthreadVC2.lib）

图3：VC++ 6.0（工程--》设置--》连接）

图4：Visual Studio 2005(project-->* property pages)

4. 书籍推荐
<< POSIX Multithread Programming Primer >>: http://download.csdn.net/source/237125

2. 接下来点击“下一步”，然后从一系列服务器列表中选择一个你认为网速最快的一个作为下载服务器。接着点击“下一步”就会出现如下图所示的界面，用来选择你想安装的程序。

     如果你不做任何修改，将默认安装Cygwin运行所需的最少的程序和组件。不过，gcc编译器不在默认安装程序之列，所以你必须选择安装gcc。具体是， 在上述窗口中的列表中展开Devel目录，找到gcc-g++一项，点击“Default”，它就变成了“Install”，同时由于程序之间的依赖性 gcc-core条目的“Default”，也变成了“Install”。

    此外，为了使gcc能正确编译源文件，还必须安装win32api库，否则会编译出错。因此，你需要在上述窗口中展开Libs目录，找到win32api一项，将它点成“Install”。

4. 安装完成后，运行Cygwin。在窗口中敲入gcc就可以直接用gcc来编译了。编译链接生成的可执行文件，系统会自动加上.exe后缀，在Cygwin 环境中可以直接运行。但如果脱离Cygwin环境，而在MS DOS下运行，则会出错。解决办法很简单，那就是将cygwin1.dll文件拷贝到C:\WINDOWS目录下即可。

在这里我想强调，如果图省事，完全可以直接将all右边的default设为install。但是这将这样你4个G的空间，所以如果你不是拥有特别大的空间的话，还是建议选择性的安装，需要什么可以随时点击先前的setup.exe加装新的组件除去以上所说的组件外，在devel下的GDB和make相信也是大多数开发者所必须的。
至此已将解决的了文章开头提及的前三项要件，而第四项man则是cygwin默认安装的，不过不是很全面，所以可以通过The Linux Documentation Project （很好很强大的文档网站）来解决，不过貌似这个网站大陆打不开，反正我是没打开，还好有香港同胞建立的mirror，比较好用的是ftp://ftp.hkmirror.org/pub/ldp/manpages/，在其中找到适合你的man版本，下载，解压到$(cygwin)目录下的/usr/share/man/下面，编辑/usr/share/misc/man.conf，文件末尾加上MANPATH /usr/share/man/man-pages-*.**即可。

好啦，如下配置后，启动cygwin，来编一个小程序helloworld热热身
随便选一个目录建立helloworld.cc文件，记事本打开，写入以下代码：
#include "stdio.h"
int
main(int args,char* argv[])
{
 printf("helloworld");
 return 0;
}
保存，启动cygwin cd到helloworld.cc文件目录，执行

$ gcc -o helloworld helloworld.cc

$ ./helloworld

helloworld