Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
* [PATCH/RFA] Fix busted logic in find_saved_register()
@ 2002-04-20 14:48 Jason R Thorpe
  2002-04-20 16:08 ` Andrew Cagney
  0 siblings, 1 reply; 6+ messages in thread
From: Jason R Thorpe @ 2002-04-20 14:48 UTC (permalink / raw)
  To: gdb-patches

[-- Attachment #1: Type: text/plain, Size: 841 bytes --]

find_saved_register() is used by mips_get_saved_register() and
the alpha_get_saved_register() in my (updated) multi-arch changes
for the Alpha target.

While investigating some testsuite failures, it appeared that
there is no way thjat find_saved_register() could possibly work
on either MIPS or Alpha, since the first thing it does on either
of those platforms is dereference a NULL pointer (said pointer is
initlaized to NULL at the top of the function).

I believe the following patch makes find_saved_register() actually
implement the logic it claims to.  It certainly fixes the problem
I had with GDB dumping core, and fixes the relevant testsuite failures.

OK to commit?

	* frame.c (find_saved_register): Avoid a NULL pointer
	dereference and actually walk the frame list.

-- 
        -- Jason R. Thorpe <thorpej@wasabisystems.com>

[-- Attachment #2: frame-patch --]
[-- Type: text/plain, Size: 798 bytes --]

Index: frame.c
===================================================================
RCS file: /cvs/src/src/gdb/frame.c,v
retrieving revision 1.7
diff -c -r1.7 frame.c
*** frame.c	17 Apr 2002 21:55:12 -0000	1.7
--- frame.c	20 Apr 2002 21:30:25 -0000
***************
*** 83,91 ****
    while (1)
      {
        QUIT;
!       frame1 = get_next_frame (frame1);
!       if (frame1 == 0 || frame1 == frame)
  	break;
        FRAME_INIT_SAVED_REGS (frame1);
        if (frame1->saved_regs[regnum])
  	addr = frame1->saved_regs[regnum];
--- 83,92 ----
    while (1)
      {
        QUIT;
!       frame1 = get_next_frame (frame);
!       if (frame1 == 0)
  	break;
+       frame = frame1;
        FRAME_INIT_SAVED_REGS (frame1);
        if (frame1->saved_regs[regnum])
  	addr = frame1->saved_regs[regnum];

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH/RFA] Fix busted logic in find_saved_register()
  2002-04-20 14:48 [PATCH/RFA] Fix busted logic in find_saved_register() Jason R Thorpe
@ 2002-04-20 16:08 ` Andrew Cagney
  2002-04-20 16:26   ` Jason R Thorpe
  0 siblings, 1 reply; 6+ messages in thread
From: Andrew Cagney @ 2002-04-20 16:08 UTC (permalink / raw)
  To: thorpej; +Cc: gdb-patches

> find_saved_register() is used by mips_get_saved_register() and
> the alpha_get_saved_register() in my (updated) multi-arch changes
> for the Alpha target.
> 
> While investigating some testsuite failures, it appeared that
> there is no way thjat find_saved_register() could possibly work
> on either MIPS or Alpha, since the first thing it does on either
> of those platforms is dereference a NULL pointer (said pointer is
> initlaized to NULL at the top of the function).
> 
> I believe the following patch makes find_saved_register() actually
> implement the logic it claims to.  It certainly fixes the problem
> I had with GDB dumping core, and fixes the relevant testsuite failures.
> 
> OK to commit?
> 
> 	* frame.c (find_saved_register): Avoid a NULL pointer
> 	dereference and actually walk the frame list.

Yes.  Looks like my:

2002-04-17  Andrew Cagney  <ac131313@redhat.com>

* frame.c (find_saved_register): Find saved registers in the next
not prev frame.
Fix PR gdb/365.

flushed out another problem.

You mention that the alpha is calling that function.  Is that directly 
or indirectly?  I'm going to eliminate the MIPS direct call.

Andrew



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH/RFA] Fix busted logic in find_saved_register()
  2002-04-20 16:08 ` Andrew Cagney
@ 2002-04-20 16:26   ` Jason R Thorpe
  2002-04-20 17:00     ` Andrew Cagney
  0 siblings, 1 reply; 6+ messages in thread
From: Jason R Thorpe @ 2002-04-20 16:26 UTC (permalink / raw)
  To: Andrew Cagney; +Cc: gdb-patches

On Sat, Apr 20, 2002 at 07:08:03PM -0400, Andrew Cagney wrote:

 > Yes.  Looks like my:
 > 
 > 2002-04-17  Andrew Cagney  <ac131313@redhat.com>
 > 
 > * frame.c (find_saved_register): Find saved registers in the next
 > not prev frame.
 > Fix PR gdb/365.
 > 
 > flushed out another problem.

Ok, I will commit the fix.

 > You mention that the alpha is calling that function.  Is that directly 
 > or indirectly?  I'm going to eliminate the MIPS direct call.

Directly.  The alpha_get_saved_register() is nearly identical to the
mips_get_saved_register().

How are you changing the MIPS target?

-- 
        -- Jason R. Thorpe <thorpej@wasabisystems.com>


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH/RFA] Fix busted logic in find_saved_register()
  2002-04-20 16:26   ` Jason R Thorpe
@ 2002-04-20 17:00     ` Andrew Cagney
  2002-04-20 18:54       ` Jason R Thorpe
  0 siblings, 1 reply; 6+ messages in thread
From: Andrew Cagney @ 2002-04-20 17:00 UTC (permalink / raw)
  To: thorpej; +Cc: gdb-patches

> Ok, I will commit the fix.
> 
>  > You mention that the alpha is calling that function.  Is that directly 
>  > or indirectly?  I'm going to eliminate the MIPS direct call.
> 
> Directly.  The alpha_get_saved_register() is nearly identical to the
> mips_get_saved_register().

If you've implemented INIT_SAVED_REGS() do you need a custom 
get_saved_register()?

> How are you changing the MIPS target?

Things will affect the MIPS at two levels.

Ref:
Andrew Cagney - [rfc] Frame based register cache / frame->unwind
http://sources.redhat.com/ml/gdb/2002-04/msg00245.html

I'm looking to change the way frames are unwound.  I'd ignore that patch 
as posted - I've managed to greatly simplify things.  Main thing to note 
that the new code doesn't use find_saved_register().  Instead it uses a 
recursive frame->register_unwind() method.

If/when this change goes through, any code using the existing 
find_saved_register() would be handed a local copy.

--

At a more theoretical [sp] level, I'm looking to rewrite the entire 
function.  Much of the MIPS complexity comes about because its REGNUM's 
are overloaded.  For instance, the hardware fp0 register might be 64 
bits but when a program (via debug info) refers to it, it is only 32 bits.

I think the way to handle this is to map debug info REGNUMs onto the 
pseudo address space and then use register_{read,write} to map them onto 
the corresponding hardware register.

This one is more theoretical as the SH5 is the first port to try to get 
this working and (apparently) it flushed out a few teething problems.

enjoy,
Andrew


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH/RFA] Fix busted logic in find_saved_register()
  2002-04-20 17:00     ` Andrew Cagney
@ 2002-04-20 18:54       ` Jason R Thorpe
  2002-04-20 22:35         ` Andrew Cagney
  0 siblings, 1 reply; 6+ messages in thread
From: Jason R Thorpe @ 2002-04-20 18:54 UTC (permalink / raw)
  To: Andrew Cagney; +Cc: gdb-patches

On Sat, Apr 20, 2002 at 08:00:06PM -0400, Andrew Cagney wrote:

 > > Directly.  The alpha_get_saved_register() is nearly identical to the
 > > mips_get_saved_register().
 > 
 > If you've implemented INIT_SAVED_REGS() do you need a custom 
 > get_saved_register()?

Ok, this is where my understanding of the call_dummy stuff starts to get
muddled :-)

The Alpha target doesn't use the generic call_dummy frame stuff, but
rather its own.  I suspect it could be converted to use the generic
stuff, but an explanation of how it's supposed to work would really help :-)

Would it be terribly evil to commit the alpha multi-arch stuff that I
have now (which would meet your condition for committing my alpha-netbsd
configuration :-), and then take a stab at converting it to generic dummy
frames?

-- 
        -- Jason R. Thorpe <thorpej@wasabisystems.com>


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH/RFA] Fix busted logic in find_saved_register()
  2002-04-20 18:54       ` Jason R Thorpe
@ 2002-04-20 22:35         ` Andrew Cagney
  0 siblings, 0 replies; 6+ messages in thread
From: Andrew Cagney @ 2002-04-20 22:35 UTC (permalink / raw)
  To: thorpej; +Cc: gdb-patches

> On Sat, Apr 20, 2002 at 08:00:06PM -0400, Andrew Cagney wrote:
> 
>  > > Directly.  The alpha_get_saved_register() is nearly identical to the
>  > > mips_get_saved_register().
>  > > If you've implemented INIT_SAVED_REGS() do you need a custom 
>  > get_saved_register()?
> 
> Ok, this is where my understanding of the call_dummy stuff starts to get
> muddled :-)
> 
> The Alpha target doesn't use the generic call_dummy frame stuff, but
> rather its own.  I suspect it could be converted to use the generic
> stuff, but an explanation of how it's supposed to work would really help :-)

Traditional dummy frames were implemented by creating a fake frame on 
the stack that contained all the registers.

Generic dummy frames instead, don't bother.  They create a fake, local 
to gdb, frame that contains the saved registers, and then calls the 
inferior function directly.  On the stack they appear like a special 
frameless function.  On paper, getting them to work is fairly easy.  See 
xstormy16-elf, cris-elf, or any new/obscure target.  Suggest grepping 
for the word ``dummy'' and copying the corresponding settings.

> Would it be terribly evil to commit the alpha multi-arch stuff that I
> have now (which would meet your condition for committing my alpha-netbsd
> configuration :-), and then take a stab at converting it to generic dummy
> frames?

Getting it multi-arched has a higher priority.

Andrew


^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2002-04-21  5:35 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-04-20 14:48 [PATCH/RFA] Fix busted logic in find_saved_register() Jason R Thorpe
2002-04-20 16:08 ` Andrew Cagney
2002-04-20 16:26   ` Jason R Thorpe
2002-04-20 17:00     ` Andrew Cagney
2002-04-20 18:54       ` Jason R Thorpe
2002-04-20 22:35         ` Andrew Cagney

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox