Re: [PATCH] in_prologue() fix

[Elena Zannoni <ezannoni at cygnus dot com>]

Ok, just to follow up on this: after personal e-mail/phone exchanges
with Jim, we agreed on a different solution. So this patch is withdrawn.

Elena


Elena Zannoni writes:
 > Jim Blandy writes:
 >  > 
 >  > > It may be that the real fix is to make ecs->stop_func_start be the
 >  > > beginning of the function where the adjusted stop_pc is. However that
 >  > > would require several changes to H.I.E. But in any event in_prologue()
 >  > > is wrong for this particular case.
 >  > 
 >  > My first question is, if HIE can find enough symbolic information to
 >  > set ecs->stop_func_{name,start,end}, how come in_prologue can't find
 >  > it?
 >  > 
 > 
 > I am not sure I understand your question.  in_prologue finds the start
 > and end of the function within which pc is (in the same way HIE does for
 > the wrong pc). Because of the way in_prologue works, the info found is
 > not compared with the input function address. Doing this would be
 > another way to fix the problem, but you would have to rewrite
 > in_prologue. What I am trying to say is that in_prologue takes 2
 > inputs: a pc and a function start address. It has to determine if the
 > pc is within the prologue of the function starting at the address. In
 > this case it gets it wrong because it doesn't think about checking if pc
 > is within the function at all. 
 > 
 > 
 >  > In other words: your explanation implies that HIE has some way to find
 >  > the function extent, but happens to be wrong because of
 >  > DECR_PC_AFTER_BREAK lossage.  But in_prologue knows the correct PC;
 >  > why can't it use the same mechanism HIE used earlier to get the right
 >  > answer?
 >  > 
 > 
 > It does use the same mechanism (find_pc_partial_function) but it
 > doesn't check the results properly.
 > 
 >  > Also, aren't there other adverse consequences when
 >  > ecs->stop_func_{name,start,end} are wrong?  I think the HIE fix is the
 >  > right thing.  HIE is painful for me too, but otherwise, you'll just
 >  > get another CR in a month.
 >  > 
 > 
 > So I thought too. But in case of breakpoint being hit,
 > bpstat_stop_status() computes the stop_pc again, and corrects it. All
 > the info is printed correctly. I haven't looked at this in too much
 > detail though. I can add a FIXME to HIE to warn for the possibility of 
 > problems down the road. I have no time now to try to fix this.
 > 
 >  > If you've tested the change on SPARC and i386, it's okay with me.
 > 
 > I tested on sparc, I will test on linux.
 > 
 > Elena
 >