[RFC/RFA/frame stuff] Fix build failure in alpha-osf1-tdep.c

[RFC/RFA/frame stuff] Fix build failure in alpha-osf1-tdep.c

[Joel Brobecker]

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

This is the second source of problems in alpha-osf-tdep.c: The
frame_info structure has become opaque, but this file still had some
references to its old fields.

Looking at the documentation in frames.h (very useful, btw), it seems
that the following change should be correct. Andrew, could you have a
close look (I am unable to test it, as I have a 3rd build failure, which
I will report shortly)? Regardless of your review, I will NOT commit
this change until have I have full build that I can test.

2003-06-03  J. Brobecker  <brobecker@gnat.com>

        * alpha-osf1-tdep.c (alpha_osf1_skip_sigtramp_frame): Replace
        references to struct frame_info fields by calls to the equivalent
        accessors. Necessary now that frame_info is opaque.
        (alpha_osf1_pc_in_sigtramp): Likewise.

Looks ok?

Thanks,
-- 
Joel

[-- Attachment #2: frames.diff --]
[-- Type: text/plain, Size: 1105 bytes --]

Index: alpha-osf1-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/alpha-osf1-tdep.c,v
retrieving revision 1.12
diff -u -3 -p -r1.12 alpha-osf1-tdep.c
--- alpha-osf1-tdep.c	3 Jun 2003 23:49:32 -0000	1.12
+++ alpha-osf1-tdep.c	4 Jun 2003 00:19:41 -0000
@@ -37,7 +37,7 @@ alpha_osf1_skip_sigtramp_frame (struct f
 
   find_pc_partial_function (pc, &name, (CORE_ADDR *) NULL, (CORE_ADDR *) NULL);
   if (PC_IN_SIGTRAMP (pc, name))
-    return frame->frame;
+    return get_frame_base (frame);
   return 0;
 }
 
@@ -50,8 +50,12 @@ alpha_osf1_pc_in_sigtramp (CORE_ADDR pc,
 static CORE_ADDR
 alpha_osf1_sigcontext_addr (struct frame_info *frame)
 {
-  return (read_memory_integer (frame->next ? frame->next->frame
-					   : frame->frame, 8));
+  struct frame_info *next_frame = get_next_frame (frame);
+
+  if (next_frame != NULL)
+    return (read_memory_integer (get_frame_base (next_frame), 8));
+  else
+    return (read_memory_integer (get_frame_base (frame), 8));
 }
 
 /* This is the definition of CALL_DUMMY_ADDRESS.  It's a heuristic that is used

Re: [RFC/RFA/frame stuff] Fix build failure in alpha-osf1-tdep.c

[Andrew Cagney]

> This is the second source of problems in alpha-osf-tdep.c: The
> frame_info structure has become opaque, but this file still had some
> references to its old fields.
> 
> Looking at the documentation in frames.h (very useful, btw), it seems
> that the following change should be correct. Andrew, could you have a
> close look (I am unable to test it, as I have a 3rd build failure, which
> I will report shortly)? Regardless of your review, I will NOT commit
> this change until have I have full build that I can test.
> 
> 2003-06-03  J. Brobecker  <brobecker@gnat.com>
> 
>         * alpha-osf1-tdep.c (alpha_osf1_skip_sigtramp_frame): Replace
>         references to struct frame_info fields by calls to the equivalent
>         accessors. Necessary now that frame_info is opaque.
>         (alpha_osf1_pc_in_sigtramp): Likewise.
> 
> Looks ok?

Yes.  If you're feeling game you could use get_frame_memory, but either way.

Andrew


> Thanks,
> -- Joel
> 
> 
> 
> Index: alpha-osf1-tdep.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/alpha-osf1-tdep.c,v
> retrieving revision 1.12
> diff -u -3 -p -r1.12 alpha-osf1-tdep.c
> --- alpha-osf1-tdep.c	3 Jun 2003 23:49:32 -0000	1.12
> +++ alpha-osf1-tdep.c	4 Jun 2003 00:19:41 -0000
> @@ -37,7 +37,7 @@ alpha_osf1_skip_sigtramp_frame (struct f
>  
>    find_pc_partial_function (pc, &name, (CORE_ADDR *) NULL, (CORE_ADDR *) NULL);
>    if (PC_IN_SIGTRAMP (pc, name))
> -    return frame->frame;
> +    return get_frame_base (frame);
>    return 0;
>  }
>  
> @@ -50,8 +50,12 @@ alpha_osf1_pc_in_sigtramp (CORE_ADDR pc,
>  static CORE_ADDR
>  alpha_osf1_sigcontext_addr (struct frame_info *frame)
>  {
> -  return (read_memory_integer (frame->next ? frame->next->frame
> -					   : frame->frame, 8));
> +  struct frame_info *next_frame = get_next_frame (frame);
> +
> +  if (next_frame != NULL)
> +    return (read_memory_integer (get_frame_base (next_frame), 8));
> +  else
> +    return (read_memory_integer (get_frame_base (frame), 8));
>  }
>  
>  /* This is the definition of CALL_DUMMY_ADDRESS.  It's a heuristic that is used

Re: [RFC/RFA/frame stuff] Fix build failure in alpha-osf1-tdep.c

[Joel Brobecker]

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

> Yes.  If you're feeling game you could use get_frame_memory, but either way.

I will have a look at get_frame_memory, at least just out of curiosity.
But right now, here is the patch I ended up committing. Since
alpha_osf1_skip_sigtramp_frame is to be slain in a separate patch,
I didn't include the update in this patch.

2003-06-03  J. Brobecker  <brobecker@gnat.com>

        * alpha-osf1-tdep.c (alpha_osf1_sigcontext_addr): Replace
        references to struct frame_info fields by calls to the equivalent
        accessors. Necessary now that frame_info is opaque.

Thanks,
-- 
Joel

[-- Attachment #2: frame.diff --]
[-- Type: text/plain, Size: 1058 bytes --]

Index: alpha-osf1-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/alpha-osf1-tdep.c,v
retrieving revision 1.12
diff -c -3 -p -r1.12 alpha-osf1-tdep.c
*** alpha-osf1-tdep.c	3 Jun 2003 23:49:32 -0000	1.12
--- alpha-osf1-tdep.c	4 Jun 2003 05:06:58 -0000
*************** alpha_osf1_pc_in_sigtramp (CORE_ADDR pc,
*** 50,57 ****
  static CORE_ADDR
  alpha_osf1_sigcontext_addr (struct frame_info *frame)
  {
!   return (read_memory_integer (frame->next ? frame->next->frame
! 					   : frame->frame, 8));
  }
  
  /* This is the definition of CALL_DUMMY_ADDRESS.  It's a heuristic that is used
--- 37,48 ----
  static CORE_ADDR
  alpha_osf1_sigcontext_addr (struct frame_info *frame)
  {
!   struct frame_info *next_frame = get_next_frame (frame);
! 
!   if (next_frame != NULL)
!     return (read_memory_integer (get_frame_base (next_frame), 8));
!   else
!     return (read_memory_integer (get_frame_base (frame), 8));
  }
  
  /* This is the definition of CALL_DUMMY_ADDRESS.  It's a heuristic that is used

Re: [RFC/RFA/frame stuff] Fix build failure in alpha-osf1-tdep.c

[Joel Brobecker]

> >2003-06-03  J. Brobecker  <brobecker@gnat.com>
> >
> >        * alpha-osf1-tdep.c (alpha_osf1_skip_sigtramp_frame): Replace
> >        references to struct frame_info fields by calls to the equivalent
> >        accessors. Necessary now that frame_info is opaque.
> >        (alpha_osf1_pc_in_sigtramp): Likewise.
> >
> >Looks ok?
> 
> Yes.  If you're feeling game you could use get_frame_memory, but
> either way.

Andrew, please forgive for not having followed the discussions about
the new frame architecture too closely (I did go and read the messages
you recently pointed out to Daniel, though!).

You are saying either way; however, my current understanding is that
get_frame_memory is not currently any different from the above, but
is still a better approach in the long run if we eventually want to be
multi-everything.  Is it correct?

I am not sure if it is really worth fixing this sort of thing now, or
worry about it later... You know the grand plan, so your call.

-- 
Joel

Re: [RFC/RFA/frame stuff] Fix build failure in alpha-osf1-tdep.c

[Andrew Cagney]

>> >2003-06-03  J. Brobecker  <brobecker@gnat.com>
>> >
>> >        * alpha-osf1-tdep.c (alpha_osf1_skip_sigtramp_frame): Replace
>> >        references to struct frame_info fields by calls to the equivalent
>> >        accessors. Necessary now that frame_info is opaque.
>> >        (alpha_osf1_pc_in_sigtramp): Likewise.
>> >
>> >Looks ok?
> 
>> 
>> Yes.  If you're feeling game you could use get_frame_memory, but
>> either way.
> 
> 
> Andrew, please forgive for not having followed the discussions about
> the new frame architecture too closely (I did go and read the messages
> you recently pointed out to Daniel, though!).
> 
> You are saying either way; however, my current understanding is that
> get_frame_memory is not currently any different from the above, but
> is still a better approach in the long run if we eventually want to be
> multi-everything.  Is it correct?

Yes.

> I am not sure if it is really worth fixing this sort of thing now, or
> worry about it later... You know the grand plan, so your call.

If the change is straight forward, might as well.  If it's a struggle, 
don't bother - I'll be looking over the code anyway to see where there 
are problems.  I'm also pretty sure that there is going to be a new 
architecture method so that:

	xxx_frame__yyy (get_frame_arch (frame), frame, ...)

can be written as:

	xxx_frame_yyy (frame, ....);

Anyway, to scare you :-)

There is some interest in fixing GDB's Java.  [insert manditory slander 
directed towards the old code] The current implementation has more 
limitiations than one can point a stick at.  Off the top of my head:
	- namespaces
	- bytecodes and a byte code target
	- backtraces through libffi
To get these working, it's going to be especially important to avoid 
globals such as current_gdbarch.

Anyway, I think the first thing is get the infrastructure working here.

Andrew

Re: [RFC/RFA/frame stuff] Fix build failure in alpha-osf1-tdep.c

[David Carlton]

On Wed, 04 Jun 2003 13:33:15 -0400, Andrew Cagney <ac131313@redhat.com> said:

> There is some interest in fixing GDB's Java.  [insert manditory
> slander directed towards the old code] The current implementation
> has more limitiations than one can point a stick at.  Off the top of
> my head:

> 	- namespaces
> 	- bytecodes and a byte code target
> 	- backtraces through libffi

We'll also need to get GCC to generate correct debug info for Java.

David Carlton
carlton@math.stanford.edu

Re: [RFC/RFA/frame stuff] Fix build failure in alpha-osf1-tdep.c

[Joel Brobecker]

> >I am not sure if it is really worth fixing this sort of thing now, or
> >worry about it later... You know the grand plan, so your call.
> 
> If the change is straight forward, might as well.  If it's a struggle, 
> don't bother - I'll be looking over the code anyway to see where there 
> are problems. 

Looking more closely, I think it's not worth bothering yet, because this
call actually hides a small cast from LONGEST to CORE_ADDR, which is not
fancied (such explicit casts are even flagged by the ARI, IIRC).

If I were to "fix" this, I would replace the call to read_memory_integer
by a call to read_memory_typed_address. But this does not have a frame
equivalent. Maybe that's something that we will have to add in the
future?

-- 
Joel