[PATCH] Fix that different function breakpoints are set at same pc address (PR gdb/12703)

Yao Qi yao@codesourcery.com
Wed Jun 29 05:36:00 GMT 2011


On 06/29/2011 09:26 AM, Terry Guo wrote:
> Hi,
> 
> I slightly modified the test case and got the below code:
> 
> 00008142 <test>:
>     8142:       250a            movs    r5, #10
> 

Could you show the source code of function "test"?  I can't figure out
how gcc generates such code.  Is it optimized by tail-call optimization?

> 
> Without Yao's patch, the "b bar" sets the break point at 0x8158. With Yao's
> patch, the "b test" still sets the break point at 0x814e that is outside the
> function test body. But the "b bar" sets the break point at 0x814e which is
> better than 0x8158. IMHO, theoretically function test could have many other
> different kinds of instruction patterns. So I think it is better to have two

There are many patterns of prologue, and that is why arm/thumb prologue
analyzer has long if/else statements to handle different cases.  My
understanding is, if GCC emit some prologue that GDB's prologue analyzer
doesn't understand, we have to improve prologue analyzer.

> enhancements one is Yao's patch which enhances the function
> thumb_analyze_prologue and make it more accurate, and another one is my
> patch which ensures the function break point to be always set inside the
> function body in a more general way. Does this solution sound good?

I am not against your approach, but prologue analyzer is still unable to
analyze some corner-case functions, so I am afraid stack backtrace on
these corner-case functions doesn't work, because stack bactrace need
the information provided from prologue analyzer.

In short, we should improve prologue analyzer to understand such
prologue as much as we can.  If it is difficult to understand some
strange prologue, such as your case, we have to resort to your patch.

-- 
Yao (齐尧)



More information about the Gdb-patches mailing list