Отсутствующие кадры в общих библиотеках на ARM

В настоящее время я работаю над средой отладки, и у меня возникают проблемы с созданием действительных файлов ядра на ARM, где сбой, вызвавший ошибку сегментации, произошел в коде общей библиотеки.

Кажется, что при вызове функции в разделяемой библиотеке указатель фрейма теряется.

Я проверил все флаги gcc, которые только мог придумать. Я не использую никаких оптимизаций, не использую -fomit-frame-pointer и пробовал использовать -rdynamic, но все безуспешно. Кроме того, я не использую abort(), поскольку я читал, что это несколько проблематично для ARM, поскольку информация о кадре не сохраняется, поскольку функция не возвращается. Вместо этого я использую memset(NULL, 0, 1), чтобы получить ошибку сегментации.

Я использую цепочку инструментов arm-cortex_a8-linux-gnuabi, которую я скомпилировал самостоятельно, используя конфигурацию crosstool-NG по умолчанию cortex-a8. (gcc 4.4.3, gsb 6.8). На хост-машине (Ubuntu) все работает нормально.

Вывод GDB примерно такой (после загрузки всех разделяемых библиотек через set solib-search-path.) Я опустил нерелевантный вывод для удобочитаемости.

(gdb) thread apply all bt full

Thread 1 (process 535):
#0 0x402ff624 in memset () from <my libc path>
No Symbol table info available.
#1 0x4011f60c in my_asserting_func () at src1.cc:5
No locals.
Backtrace stopped: frame did not save the PC

src1.cc:

#include <src1.h>
#include <string.h>
void my_asserting_func(void) 
{ 
    memset(NULL, 0, 1); 
}

основной.cc:

#include <src1.h>
int main(void)
{
    my_asserting_func();
    return 0;
}

Любая помощь будет очень признательна,

Андрей.

PS: используя objump, вот дизассемблирование функции my_asserting_func:

00000654 <_Z17my_asserting_funcv>:
654:    e1a0c00d        mov      ip, sp
658:    e92dd800        push     {fp, ip, lr, pc}
65c:    e24cb004        sub      fp, ip, #4
660:    e3a00000        mov      r0, #0
664:    e3a01000        mov      r1, #0
668:    e3a02001        mov      r2, #1
66c:    ebffffb1        bl       538 <_init+0x38>
670:    e89da800        ldm      sp, {fp, sp, pc}

person Andrew    schedule 29.08.2011    source источник
comment
Вы разборку смотрели? Это может дать вам некоторые подсказки, почему gdb, похоже, не может пройтись по стеку.   -  person 80x25    schedule 30.08.2011
comment
@ 80x25: я разместил ассемблерный код my_asserting_func. К сожалению, я не так сообразителен, когда дело доходит до сборки, поэтому любая помощь будет очень признательна. Спасибо, Эндрю.   -  person Andrew    schedule 31.08.2011
comment
Хм, ничего не торчит как проблема в сборке этой функции. Также было бы полезно посмотреть на разборку main. Я бы сказал, задайте вопрос в списке рассылки gdb, возможно, это может быть ошибка в gdb, или, по крайней мере, они смогут рассказать вам больше о том, почему gdb терпит неудачу. @Андрей:   -  person 80x25    schedule 11.09.2011