GDB не находит номера строк, objdump -

Я использую DDD / GDB для отладки самодельной игры, работающей на NintendoDS, созданной с помощью "arm-eabi-gcc (devkitARM release 32) 4.5.1". К вашему сведению, я загрузил распакованный двоичный файл .elf (файл больше не размещен) на случай, если кто-то захочет воспроизвести некоторые из шагов, описанных ниже.

  • Я прошу gdb предоставить список одной из функций, находящихся в GameScript.o (GobExpression :: eval), он отлично с этим справляется.

  • Я прошу gdb предоставить список SimpleGob :: play в том же GameScript.o, он жалуется, что «Для SimpleGob :: play не известен номер строки». (сессия arm-eabi-gdb чуть ниже :)

arm-eabi-gdb AppleAssault.elf

GNU gdb (GDB) 7.2
This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-eabi".
Reading symbols from AppleAssault.elf...done.
(gdb) list GobExpression::eval
342    bool eval(s16 data[REGISTERS], iGun **extra=0) {
343         GobCollision gc[2]={{0,0,data},{0,0,0}};
344         return eval(gc,extra);
345       }
346     
347       bool eval(GobCollision* c, iGun **extra=0) {
348         s16 *data=c[0].data;
349         s16 stack[STACKSIZE]; int sp=0;
350         u8 op;
351         if (!code) return true;
gdb) list SimpleGob::play
play    play()  
(gdb) list SimpleGob::play
No line number known for SimpleGob::play.

Однако, если я вызываю arm-eabi-objdump -drl AppleAssault.elf, он, очевидно, находит некоторые номера строк, как они упоминаются в дампе:

0203c7f8 <_ZN9SimpleGob4playEv>:
_ZN9SimpleGob4playEv():
/beetle/hobby/DS/dsgametools/branches/companim/libgeds/source/GameObject.cpp:1710
 203c7f8:       b5f0            push    {r4, r5, r6, r7, lr}
 203c7fa:       465f            mov     r7, fp
 203c7fc:       4656            mov     r6, sl
 203c7fe:       464d            mov     r5, r9
 203c800:       4644            mov     r4, r8
 203c802:       b4f0            push    {r4, r5, r6, r7}
 203c804:       b0a7            sub     sp, #156        ; 0x9c
_ZN9CommonGob11gobDoChecksEv():
/beetle/hobby/DS/dsgametools/branches/companim/libgeds/source/GameObject.cpp:1430
 203c806:       7c03            ldrb    r3, [r0, #16]
_ZN9SimpleGob4playEv():
/beetle/hobby/DS/dsgametools/branches/companim/libgeds/source/GameObject.cpp:1710
 203c808:       1c05            adds    r5, r0, #0
_ZN9CommonGob11gobDoChecksEv():
/beetle/hobby/DS/dsgametools/branches/companim/libgeds/source/GameObject.cpp:1430
 203c80a:       2b00            cmp     r3, #0
 203c80c:       d100            bne.n   203c810 <_ZN9SimpleGob4playEv+0x18>
 203c80e:       e099            b.n     203c944 <_ZN9SimpleGob4playEv+0x14c>

Файл компилируется с arm-eabi-g++ -MMD -MP -MF /beetle/hobby/DS/dsgametools/branches/companim/libgeds/build/GameObject.d -g -march=armv5te -mtune=arm946e-s -fomit-frame-pointer -ffast-math -mthumb -mthumb-interwork {include path stripped} -DARM9 -fno-rtti -Wall -O2 -c /beetle/hobby/DS/dsgametools/branches/companim/libgeds/source/GameObject.cpp -o GameObject.o, таким образом, с включенными отладочными символами, упаковывается в архив .a и, наконец, связывается с программой. Перекомпиляция с -O0, похоже, не помогает.

Я видел обходной путь в GDB не может найти номера строк, предлагающий используйте add-symbol-file, хотя я не совсем знаю, какой файл символов я бы добавил ... Мне не хватает тонкой ключевой концепции отладочных символов GDB, которая объяснила бы, какие (некоторые части) мои программы отсутствуют для GDB чтобы иметь возможность аннотировать его номерами строк?


person PypeBros    schedule 23.01.2012    source источник
comment
GameObject.cpp включен в GameScript.cpp, если это важно. Файл .map, созданный во время компоновки, подтверждает, что обе функции SimpleGob :: play и GobExpression :: eval находятся в GameScript.o - но это не должно вводить в заблуждение gdb, не так ли?   -  person PypeBros    schedule 23.01.2012
comment
Определяется ли случайная функция как встроенная?   -  person sessyargc.jp    schedule 24.01.2012
comment
@ sessionsyargc.jp: они вызывают некоторые встроенные методы, но не сами по себе. SimpleGob :: play - это даже виртуальный метод, который вызывается как таковой.   -  person PypeBros    schedule 24.01.2012


Ответы (1)


Попробуйте -gstabs+ при компиляции с g++, чтобы попробовать с отладочной информацией расширений GNU (понимается только gdb).

person devmusings    schedule 24.01.2012
comment
ух ты. Это просто сработало. Любой шанс stackoverflow.com/questions/8980566/ вдохновил вас? (теперь я просто должен понять почему: P) - person PypeBros; 24.01.2012