This is the mail archive of the
gdb-patches@sourceware.cygnus.com
mailing list for the GDB project.
Re: [PATCH] in_prologue() fix
- To: Elena Zannoni <ezannoni at cygnus dot com>
- Subject: Re: [PATCH] in_prologue() fix
- From: Elena Zannoni <ezannoni at cygnus dot com>
- Date: Tue, 2 May 2000 16:10:39 -0400 (EDT)
- Cc: Jim Blandy <jimb at cygnus dot com>, gdb-patches at sourceware dot cygnus dot com
- References: <14598.9829.764888.505476@kwikemart.cygnus.com><nphfcojymh.fsf@zwingli.cygnus.com><14599.32044.511265.33190@kwikemart.cygnus.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
>