Walter Zambotti Posted November 9, 2020 Posted November 9, 2020 So I'm trying to debug a 32 bit C compiler circa 1983 that only compiles in 32 bit. I have the compiler working in Linux Ubuntu 18.04 and later with multiverse (32 bit) support installed. I thought to myself PI OS would have to be one the most popular used and supported 32 bit OS, so let's compile and debug the the 32 application in a complete 32 environment. However on the PI OS 32 bit while I have managed to compile to compiler with no issues it doesn't execute and gets seg faults. No problem I can debug it! Except I can't because if I use the debugger via Geany or directly it complains it can't find variables higher up in the stack. gdb $ where full (shows that the variable is known and is on scope) but gdb $ print said_function::said_variable (complains it can't find the variable). Topic on stackoverflow refers https://stackoverflow.com/questions/64728124/linux-gdb-cannot-print-variable-in-stack Unfortunately the question has bee closed (prematurely I believe) and so no one my answer the question there! Hence why I'm here! (gdb) where full #0 0xb6fbc1dc in strlen () from /usr/lib/arm-linux-gnueabihf/libarmmem-v7l.so No symbol table info available. #1 0x0001076c in WrStr (s=0x0) at ansifront.c:71 len = 213201 #2 0x00011698 in PrintTok (x=511) at ansifront.c:419 No locals. #3 0x00011f78 in WrTQual (ts=0x31647 <mainstk+951>) at ansifront.c:646 No locals. #4 0x00011fbc in WrTSpec (ts=0x31647 <mainstk+951>) at ansifront.c:654 No locals. #5 0x0001ccc4 in WrNTSpec (tspec=0x31647 <mainstk+951>) at decl.c:561 type = 4 '\004' #6 0x0001d0f0 in WrXDecl (vdecl=0xbefff128, isfdef=0) at decl.c:676 tsvdecl = {vd_var = 0x1d0fc <WrXDecl+636> "", vd_type = 0x0, vd_tspec = 0x31647 <mainstk+951>, vd_prev = 0x31647 <mainstk+951>} #7 0x0001d9c0 in WrOSPLst (plst=0x3163b <mainstk+939>, fndecl=0x3160d <mainstk+893>) at decl.c:906 vdecl = {vd_var = 0x34098 <tmpstk+8> "winpath", vd_type = 0x0, vd_tspec = 0x31647 <mainstk+951>, vd_prev = 0x0} tlp = 0x31643 <mainstk+947> ilp = 0x34090 <tmpstk> #8 0x0001e118 in RdGDecl () at decl.c:1084 params = 0x3163b <mainstk+939> isfunct = 1 needsimi = 0 '\000' tspec = 0x31605 <mainstk+885> vdecl = 0x3160d <mainstk+893> #9 0x00013f34 in main (argc=1, argv=0xbefff2c4) at ansifront.c:1499 No locals. (gdb) print RdGDecl::params No symbol "params" in specified context. (gdb) print params No symbol "params" in current context. (gdb) Looking in the manual there is no mention of referencing variables in sub blocks other than mentioning that a block must be active in order to do this. 'where full' confirms this is the case on line #8. Someone in the stackoverflow question mentioned something about stack frames and 8 byte. I assume they mean alignment. Looking at the addresses for the variables on the stack they seems to be suspiciously non 8 byte alligned (params = 0x3163b is an odd value). I have looked for a compiler option to enforce 8 byte stack alignment but could not find one. Does anyone know of such an option? Also if anyone feels my stackoverflow question was prematurely closed I would appreciate if you could leave some additional comments on that question, maybe asking for it to be re-opened (if you feel appropriate)! Walter
@lex Posted November 9, 2020 Posted November 9, 2020 What are the compiler options in use? You could try to put a break before you call **WrTSpec** and check the stack. You can also use valgrind to check for stack corruption.
Walter Zambotti Posted November 12, 2020 Author Posted November 12, 2020 The simple answer turns out to be the selection of the correct frame number. Print function::variable does not set the frame number for you, and it must be manually set by frame #. Which in my example is 8!
Recommended Posts