📄 debuging_applications.html
字号:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html><head> <title></title> <link rel="stylesheet" media="screen" type="text/css" href="./style.css" /> <link rel="stylesheet" media="screen" type="text/css" href="./design.css" /> <link rel="stylesheet" media="print" type="text/css" href="./print.css" /> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /></head><body><a href=start.html>start</a></br><div class="toc"><div class="tocheader toctoggle" id="toc__header">Table of Contents</div><div id="toc__inside"><ul class="toc"><li class="level1"><div class="li"><span class="li"><a href="#application_debugging" class="toc">Application Debugging</a></span></div><ul class="toc"><li class="level2"><div class="li"><span class="li"><a href="#stack_checking" class="toc">Stack Checking</a></span></div></li><li class="level2"><div class="li"><span class="li"><a href="#analyzing_traces" class="toc">Analyzing Traces</a></span></div></li></ul></li></ul></div></div><h1><a name="application_debugging" id="application_debugging">Application Debugging</a></h1><div class="level1"><p> Sometimes the best way to debug an application is also the easy way. Here are some things to check before firing up gdb.</p></div><!-- SECTION [1-159] --><h2><a name="stack_checking" id="stack_checking">Stack Checking</a></h2><div class="level2"><p>Many application errors are the result of stack overflows. This is where data normally contained in the stack overflows into data in the bss section, or worse, in executable code space. To help debug this issue, the <code>bfin-uclinux-gcc</code> compiler supports stack checking: </p><pre class="code">bfin-uclinux-gcc -fstack-limit-symbol=_stack_start application.c</pre><p> If the application’s stack is overflowed, then an error will be generated and the application will exit gracefully.</p><p>Stack sizes can be increased on the target with the <code>flhdr</code> application: </p><pre class="code">flthdr -s 8192 application</pre><p> This sets the application stack size to 8k (8192 bytes).</p><p>You can also control the stack size while compiling your application: </p><pre class="code">bfin-uclinux-gcc -Wl,-elf2flt="-s 8192" application.c</pre></div><!-- SECTION [160-963] --><h2><a name="analyzing_traces" id="analyzing_traces">Analyzing Traces</a></h2><div class="level2"><p>One feature of the Blackfin that comes in handy is the hardware trace buffer. The cpu automatically tracks the last 16 code flow changes in this buffer. When an application crashes and the kernel catches it, the hardware buffer will automatically be displayed.</p><p>For example, let’s look at a program that uses unaligned data access. </p><pre class="code c"><span class="kw4">int</span> main<span class="br0">(</span><span class="br0">)</span><span class="br0">{</span> <span class="kw4">char</span> c<span class="br0">[</span><span class="nu0">10</span><span class="br0">]</span>; <span class="kw4">int</span> i; i = *<span class="br0">(</span><span class="kw4">int</span>*<span class="br0">)</span><span class="br0">(</span>c<span class="nu0">+1</span><span class="br0">)</span>; <span class="kw1">return</span> <span class="nu0">0</span>;<span class="br0">}</span></pre><p>Just compile this <code>hello.c</code> and transfer it to the target. When we run it, the application should crash on us.</p><pre class="code">root:~> ./helloData access misaligned address violation - Attempted misaligned data memory or data cache access.DCPLB_FAULT_ADDR=029aff30CURRENT PROCESS: <removed for readability>Hardware Trace: 0 Target : <00004358>{_trap_c+0} Source : <0000710e>{exception_to_level5+146} 1 Target : <0000707c>{exception_to_level5+0} Source : <00007078>{ex_trap_c+44} 2 Target : <0000704c>{ex_trap_c+0} Source : <00007198>{_trap+40} 3 Target : <00007170>{_trap+0} Source : <029a0154>{hello+0x114} 4 Target : <029a0144>{hello+0x104} Source : <029a0234>{hello+0x1f4} 5 Target : <029a022e>{hello+0x1ee} Source : <029a0222>{hello+0x1e2} 6 Target : <029a0212>{hello+0x1d2} Source : <029a0f88>{hello+0xf48} 7 Target : <029a0f78>{hello+0xf38} Source : <029a020e>{hello+0x1ce} 8 Target : <029a0202>{hello+0x1c2} Source : <029a2cf8>{hello+0x2cb8} 9 Target : <029a2cf4>{hello+0x2cb4} Source : <029a2cd4>{hello+0x2c94}10 Target : <029a2cc8>{hello+0x2c88} Source : <029a01bc>{hello+0x17c}11 Target : <029a01b8>{hello+0x178} Source : <029a0180>{hello+0x140}12 Target : <029a0170>{hello+0x130} Source : <029a2cc6>{hello+0x2c86}13 Target : <029a2ca8>{hello+0x2c68} Source : <029a2cf0>{hello+0x2cb0}14 Target : <029a2cf0>{hello+0x2cb0} Source : <029a0134>{hello+0xf4}15 Target : <029a0130>{hello+0xf0} Source : <029a0118>{hello+0xd8} <removed for readability></pre><p>We can take this trace output and combine it with the disassembled output from the application. What we’re interested is the last few lines before code in the kernel is executed (trace number 3 and 4 in the above example). To get the disassembled output, we run <code>bfin-uclinux-objdump</code> on the .gdb file produced while compiling the application into a flat binary. Then we check out the offsets in the output that were indicated by the hardware trace. We probably want to look at the code between 0×104 and 0×114 (taken from trace number 3 and 4). </p><pre class="code">host$ bfin-uclinux-objdump -d hello.gdb <removed for readability>00000104 <_main>: 104: 00 e8 04 00 LINK 0x10; 108: 57 32 P2=FP; 10a: aa 6f P2+=-11; 10c: 10 91 R0=[P2]; 10e: c0 bb [FP-16]=R0; 110: 00 60 R0=0x0(x); 112: 01 e8 00 00 UNLINK; 116: 10 00 RTS; <removed for readability></pre><p>Indeed, we see that the register P2 is set to an unaligned value and then dereferenced. </p></div><!-- SECTION [964-] --></body></html>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -