gdb方式遍历EG(symbol_table) 哈希表的key

Sara Golemon写过一篇文章，里面提到：“是否存在特别的地方可以找到GLOBALS数组？”答案是“存在”，就是EG(symbol_table)－Executor Globals结构，她也给出了找的具体实例，如下

PHP_FUNCTION(confirm_getGlobal_compiled) {

    char *varname;

    int varname_len;

    zval **varvalue;

    if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "s", &varname, &varname_len) == FAILURE) {

        RETURN_NULL();

    }

    if (zend_hash_find(&EG(symbol_table), varname, varname_len + 1, (void**)&varvalue) == FAILURE) {

        php_error_docref(NULL TSRMLS_CC, E_NOTICE, "Undefined variable: %s", varname);

        RETURN_NULL();

    }

    *return_value = **varvalue;

    zval_copy_ctor(return_value);

}

编译成so加载后，编写php测试代码

$abc = 'string';

$def = 'string2';

var_dump(confirm_getGlobal_compiled('abc'));

执行结果

string(6) "string"

大家可能感觉奇怪，为什么多写了一个def变量，这就是下面要进行的，一起来看下EG这个hashtable

gdb --args bin/php -c php.ini a.php

调试代码如下

(gdb) b renzhi.c : 301     //在写的扩展地方加上断点

No source file named renzhi.c.

Make breakpoint pending on future shared library load? (y or [n]) y

Breakpoint 1 (renzhi.c : 301) pending.

(gdb) r   //运行到断点处

Starting program: /root/php-src-5.3/bin/php -c php.ini ceshi.php

warning: .dynamic section for "/lib/libc.so.6" is not at the expected address

warning: difference appears to be caused by prelink, adjusting expectations

[Thread debugging using libthread_db enabled]

Breakpoint 1, zif_confirm_getGlobal_compiled (ht=1, return_value=0x837a43c, return_value_ptr=0x0, this_ptr=0x0, return_value_used=1)

    at /root/php-src-5.3/ext/renzhi/renzhi.c:305

305         if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "s", &varname, &varname_len) == FAILURE) {

(gdb) n

309         if (zend_hash_find(&EG(symbol_table), varname, varname_len + 1, (void**)&varvalue) == FAILURE) {

(gdb) step    //进入zend_hash_find哈希查找函数

zend_hash_find (ht=0x82e3250, arKey=0x837a42c "abc", nKeyLength=4, pData=0xbfffc484) at /root/php-src-5.3/Zend/zend_hash.c:872