[6] What if EXTRA_FRAME_INFO wasn't required

[6] What if EXTRA_FRAME_INFO wasn't required

[Andrew Cagney]

Joel,

If the need to convert EXTRA_FRAME_INFO was dropped as a barrier to 
having HP/UX multi-arch partial, would anything else be left?

I'm wondering how much further the bar needs to be lowered before HP/UX 
accidently falls over the multi-arch requirement [#include vision of 
HP/UX trying to play the `the stick game', where the sole objective is 
to jump / step / fall / crawl over a stick lying flat on the ground, and 
still failing :-]

--

My cunning plan is to, since GDB has had so much significant recent 
change, reset slightly peoples expectations for this new release.  Even 
releases are generally associated with stability problems :-)

Andrew

Re: [6] What if EXTRA_FRAME_INFO wasn't required

[Joel Brobecker]

> If the need to convert EXTRA_FRAME_INFO was dropped as a barrier to 
> having HP/UX multi-arch partial, would anything else be left?

If my notes are still correct, the answer is no. I think I can
double-check sometime this afternoon. 

(this is for hppa 32 bits, hppa 64 bits is slightly more difficult for
me, due to a lack of a convenient development machine... The testdrive
program work well enough, but I must say they do not provide the most
friendly environment)

> I'm wondering how much further the bar needs to be lowered before HP/UX 
> accidently falls over the multi-arch requirement [#include vision of 
> HP/UX trying to play the `the stick game', where the sole objective is 
> to jump / step / fall / crawl over a stick lying flat on the ground, and 
> still failing :-]

:-).

-- 
Joel

(Funny you would ask this today, I was about to have a look at this
macro this afternoon)

Re: [6] What if EXTRA_FRAME_INFO wasn't required

[Andrew Cagney]

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

>> If the need to convert EXTRA_FRAME_INFO was dropped as a barrier to 
>> having HP/UX multi-arch partial, would anything else be left?
> 
> 
> If my notes are still correct, the answer is no. I think I can
> double-check sometime this afternoon. 
> 
> (this is for hppa 32 bits, hppa 64 bits is slightly more difficult for
> me, due to a lack of a convenient development machine... The testdrive
> program work well enough, but I must say they do not provide the most
> friendly environment)

Yep.

The attached appears to drag HP, kicking and screaming, into multi-arch 
partial.  It isn't a ``get out of goal free card'' though.  HP/UX needs 
to leap-frog all the init frame stuff and start using the latest frame 
code.  Otherwize it will just be deleted for relying on deprecated 
mechanisms.

I also don't know if it actually works.

Andrew


[-- Attachment #2: diffs --]
[-- Type: text/plain, Size: 7207 bytes --]

2003-03-30  Andrew Cagney  <cagney@redhat.com>

	* config/pa/tm-hppa.h (init_frame_pc_default): Declare.
	(GDB_MULTI_ARCH): Set to GDB_MULTI_ARCH_PARTIAL.
	* gdbarch.sh: Allow FRAME_FIND_SAVED_REGS and EXTRA_FRAME_INFO
	when partially multi-arch.
	(CALL_DUMMY_LOCATION): Allow previous definition.
	(DEPRECATED_PC_IN_CALL_DUMMY): Ditto.
	(DEPRECATED_USE_GENERIC_DUMMY_FRAMES): Ditto.
	(DEPRECATED_FRAME_INIT_SAVED_REGS): Define as
	deprecated_get_frame_saved_regs when EXTRA_FRAME_INFO.
	* gdbarch.h: Re-generate.
	* hppa-hpux-tdep.c: Include "frame.h".
	* Makefile.in (hppa-hpux-tdep.o): Update dependencies.
	* frame.h (DEPRECATED_FRAME_INIT_SAVED_REGS): Definition moved to
	"gdbarch.sh".
	(struct frame_saved_regs): Set the size of regs to "a very large
	number".
	* frame.c (deprecated_get_frame_saved_regs): Assert that "a very
	large number" is large enough for all the registers.
	
Index: Makefile.in
===================================================================
RCS file: /cvs/src/src/gdb/Makefile.in,v
retrieving revision 1.354
diff -u -r1.354 Makefile.in
--- Makefile.in	30 Mar 2003 14:52:41 -0000	1.354
+++ Makefile.in	31 Mar 2003 00:00:15 -0000
@@ -1749,7 +1749,7 @@
 	$(gdb_stat_h) $(gdb_wait_h) $(gdbcore_h) $(gdbcmd_h) $(target_h) \
 	$(symfile_h) $(objfiles_h)
 hppa-hpux-tdep.o: hppa-hpux-tdep.c $(defs_h) $(arch_utils_h) $(gdbcore_h) \
-	$(osabi_h) $(gdb_string_h)
+	$(osabi_h) $(gdb_string_h) $(frame_h)
 hppab-nat.o: hppab-nat.c $(defs_h) $(inferior_h) $(target_h) $(regcache_h)
 hppah-nat.o: hppah-nat.c $(defs_h) $(inferior_h) $(target_h) $(gdbcore_h) \
 	$(gdb_wait_h) $(regcache_h)
Index: frame.c
===================================================================
RCS file: /cvs/src/src/gdb/frame.c,v
retrieving revision 1.89
diff -u -r1.89 frame.c
--- frame.c	26 Mar 2003 00:00:07 -0000	1.89
+++ frame.c	31 Mar 2003 00:00:18 -0000
@@ -1674,6 +1674,8 @@
   if (saved_regs_addr == NULL)
     {
       struct frame_saved_regs saved_regs;
+      gdb_assert ((sizeof (saved_regs.regs) / sizeof (saved_regs.regs[0]))
+		  > NUM_REGS);
       FRAME_FIND_SAVED_REGS (frame, saved_regs);
       memcpy (frame->saved_regs, &saved_regs, SIZEOF_FRAME_SAVED_REGS);
     }
Index: frame.h
===================================================================
RCS file: /cvs/src/src/gdb/frame.h,v
retrieving revision 1.76
diff -u -r1.76 frame.h
--- frame.h	24 Mar 2003 03:54:47 -0000	1.76
+++ frame.h	31 Mar 2003 00:00:20 -0000
@@ -329,7 +329,8 @@
        regs[SP_REGNUM] is different.  It holds the actual SP, not the
        address at which it was saved.  */
 
-    CORE_ADDR regs[NUM_REGS];
+    /* Note that 1000 is simply "a very large number".  */
+    CORE_ADDR regs[1000];
   };
 #endif
 
@@ -461,8 +462,6 @@
 
 
 #ifdef FRAME_FIND_SAVED_REGS
-/* XXX - deprecated */
-#define DEPRECATED_FRAME_INIT_SAVED_REGS(FI) deprecated_get_frame_saved_regs (FI, NULL)
 extern void deprecated_get_frame_saved_regs (struct frame_info *,
 					     struct frame_saved_regs *);
 #endif
Index: gdbarch.sh
===================================================================
RCS file: /cvs/src/src/gdb/gdbarch.sh,v
retrieving revision 1.213
diff -u -r1.213 gdbarch.sh
--- gdbarch.sh	30 Mar 2003 14:32:09 -0000	1.213
+++ gdbarch.sh	31 Mar 2003 00:00:22 -0000
@@ -517,8 +517,8 @@
 # behaviour here (and hence entrench it further) gdbarch simply
 # reqires that these methods be set up from the word go.  This also
 # avoids any potential problems with moving beyond multi-arch partial.
-v:1:DEPRECATED_USE_GENERIC_DUMMY_FRAMES:int:deprecated_use_generic_dummy_frames:::::1::0
-v:1:CALL_DUMMY_LOCATION:int:call_dummy_location:::::AT_ENTRY_POINT::0
+v::DEPRECATED_USE_GENERIC_DUMMY_FRAMES:int:deprecated_use_generic_dummy_frames:::::1::0
+v::CALL_DUMMY_LOCATION:int:call_dummy_location:::::AT_ENTRY_POINT::0
 f:2:CALL_DUMMY_ADDRESS:CORE_ADDR:call_dummy_address:void:::0:0::gdbarch->call_dummy_location == AT_ENTRY_POINT && gdbarch->call_dummy_address == 0
 v:2:CALL_DUMMY_START_OFFSET:CORE_ADDR:call_dummy_start_offset::::0:-1:::0x%08lx
 v:2:CALL_DUMMY_BREAKPOINT_OFFSET:CORE_ADDR:call_dummy_breakpoint_offset::::0:-1::gdbarch->call_dummy_breakpoint_offset_p && gdbarch->call_dummy_breakpoint_offset == -1:0x%08lx::CALL_DUMMY_BREAKPOINT_OFFSET_P
@@ -529,7 +529,7 @@
 # is false, the corresponding function works.  This simplifies the
 # migration process - old code, calling DEPRECATED_PC_IN_CALL_DUMMY(),
 # doesn't need to be modified.
-F:1:DEPRECATED_PC_IN_CALL_DUMMY:int:deprecated_pc_in_call_dummy:CORE_ADDR pc, CORE_ADDR sp, CORE_ADDR frame_address:pc, sp, frame_address::generic_pc_in_call_dummy:generic_pc_in_call_dummy
+F::DEPRECATED_PC_IN_CALL_DUMMY:int:deprecated_pc_in_call_dummy:CORE_ADDR pc, CORE_ADDR sp, CORE_ADDR frame_address:pc, sp, frame_address::generic_pc_in_call_dummy:generic_pc_in_call_dummy
 v:1:CALL_DUMMY_P:int:call_dummy_p::::0:-1
 v::CALL_DUMMY_WORDS:LONGEST *:call_dummy_words::::0:legacy_call_dummy_words::0:0x%08lx
 v::SIZEOF_CALL_DUMMY_WORDS:int:sizeof_call_dummy_words::::0:legacy_sizeof_call_dummy_words::0
@@ -820,15 +820,16 @@
 /* If any of the following are defined, the target wasn't correctly
    converted. */
 
-#if GDB_MULTI_ARCH
 #if defined (EXTRA_FRAME_INFO)
-#error "EXTRA_FRAME_INFO: replaced by struct frame_extra_info"
+#if GDB_MULTI_ARCH > GDB_MULTI_ARCH_PARTIAL
+#error "EXTRA_FRAME_INFO: replaced by frame unwinder"
 #endif
+#define DEPRECATED_FRAME_INIT_SAVED_REGS(FI) deprecated_get_frame_saved_regs (FI, NULL)
 #endif
 
-#if GDB_MULTI_ARCH
 #if defined (FRAME_FIND_SAVED_REGS)
-#error "FRAME_FIND_SAVED_REGS: replaced by DEPRECATED_FRAME_INIT_SAVED_REGS"
+#if GDB_MULTI_ARCH > GDB_MULTI_ARCH_PARTIAL
+#error "FRAME_FIND_SAVED_REGS: replaced by frame unwinder"
 #endif
 #endif
 
Index: hppa-hpux-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/hppa-hpux-tdep.c,v
retrieving revision 1.4
diff -u -r1.4 hppa-hpux-tdep.c
--- hppa-hpux-tdep.c	29 Mar 2003 23:29:47 -0000	1.4
+++ hppa-hpux-tdep.c	31 Mar 2003 00:00:22 -0000
@@ -22,6 +22,7 @@
 #include "gdbcore.h"
 #include "osabi.h"
 #include "gdb_string.h"
+#include "frame.h"
 
 /* Forward declarations.  */
 extern void _initialize_hppa_hpux_tdep (void);
Index: config/pa/tm-hppa.h
===================================================================
RCS file: /cvs/src/src/gdb/config/pa/tm-hppa.h,v
retrieving revision 1.41
diff -u -r1.41 tm-hppa.h
--- config/pa/tm-hppa.h	26 Mar 2003 22:39:53 -0000	1.41
+++ config/pa/tm-hppa.h	31 Mar 2003 00:00:31 -0000
@@ -24,12 +24,15 @@
 
 #include "regcache.h"
 
-#define GDB_MULTI_ARCH 0
+#define GDB_MULTI_ARCH 1
 
 /* NOTE: cagney/2002-11-24: This is a guess.  */
 #define DEPRECATED_USE_GENERIC_DUMMY_FRAMES 0
 #define CALL_DUMMY_LOCATION ON_STACK
 #define DEPRECATED_PC_IN_CALL_DUMMY(pc, sp, frame_address) deprecated_pc_in_call_dummy_on_stack (pc, sp, frame_address)
+/* HACK: cagney/2003-03-30: This is to avoid the need to #include
+   "arch-utils.h", and that just doesn't work.  */
+extern CORE_ADDR init_frame_pc_default (int fromleaf, struct frame_info *prev);
 #define DEPRECATED_INIT_FRAME_PC(l,f) (init_frame_pc_default (l, f))
 
 /* Forward declarations of some types we use in prototypes */

Re: [6] What if EXTRA_FRAME_INFO wasn't required

[Joel Brobecker]

> The attached appears to drag HP, kicking and screaming, into multi-arch 
> partial.  It isn't a ``get out of goal free card'' though.  HP/UX needs 
> to leap-frog all the init frame stuff and start using the latest frame 
> code.  Otherwize it will just be deleted for relying on deprecated 
> mechanisms.
> 
> I also don't know if it actually works.

Will try it out. I also identified a few macros that were not converted
yet, but all of them should be easy to do, except one (FIX_CALL_DUMMY)
which I understand should be replaced in the relatively near future.

Can I commit your patch if it turns out to be working, or would you
prefer to do it?

Thanks,
-- 
Joel

BTW: The next steps in the plan, once HP/UX is multiarch partial, is to
shuffle a bit all the declarations in tm-hppa.h to put them either in
a hppa-tdep.h file, or even hppa-tdep.c if possible. This should help us
reduce the size of tm-hppa.h, and pave the way to its eventual deletion.

Next will be the multi-arching of hppa64, which I hope will be a
reasonably small task, given that hppa is already done.

Then I will look at getting rid of the deprecated mechanisms.

Next (if I'm not dead by then :-) will be to have a look at these
HP-specific macros they added. Maybe I'll even look at them before
working on the use of deprecated functions.

Re: [6] What if EXTRA_FRAME_INFO wasn't required

[Andrew Cagney]

> The attached appears to drag HP, kicking and screaming, into multi-arch 
>> partial.  It isn't a ``get out of goal free card'' though.  HP/UX needs 
>> to leap-frog all the init frame stuff and start using the latest frame 
>> code.  Otherwize it will just be deleted for relying on deprecated 
>> mechanisms.
>> 
>> I also don't know if it actually works.
> 
> 
> Will try it out. I also identified a few macros that were not converted
> yet, but all of them should be easy to do, except one (FIX_CALL_DUMMY)
> which I understand should be replaced in the relatively near future.
> 
> Can I commit your patch if it turns out to be working, or would you
> prefer to do it?

You can.

Andrew

Re: [6] What if EXTRA_FRAME_INFO wasn't required

[Andrew Cagney]

> 
> Will try it out. I also identified a few macros that were not converted
> yet, but all of them should be easy to do, except one (FIX_CALL_DUMMY)
> which I understand should be replaced in the relatively near future.

I need to find an excuse for doing it.  Something as perverted as 
modifying the d10v to use generic dummy frames that are on the stack 
should do the trick :-)

I'm guessing that the entire dummy mess can be replaced with a single 
simple:

	push_dummy_breakpoint()

with a default implementation looking something like:

	BREAKPOINT_FROM_PC(addr, len, bytes);
	write_memory (addr, len, bytes);

> Can I commit your patch if it turns out to be working, or would you
> prefer to do it?

I've committed the bulk of it.  Suggest giving multi-arch partial a 
wirl.  Oh, I thought I glimpsed some ->frame or ->pc references in some 
of the HP code :-(

Andrew

Re: [6] What if EXTRA_FRAME_INFO wasn't required

[Joel Brobecker]

> I've committed the bulk of it.  Suggest giving multi-arch partial a 
> wirl.  Oh, I thought I glimpsed some ->frame or ->pc references in some 
> of the HP code :-(

I have made a try last week before I left on a 2 weeks trip. The build
fails because some macros need to be converted first. I was planning to
do this when I'm back (end of next week).

-- 
Joel

Re: [6] What if EXTRA_FRAME_INFO wasn't required

[Joel Brobecker]

Andrew,

> If the need to convert EXTRA_FRAME_INFO was dropped as a barrier to 
> having HP/UX multi-arch partial, would anything else be left?

Good news, it turned out that this macro was actually not needed (the
new field was never used). I therefore just deleted it. I guess you can
now finally make the frame_info struct opaque.

Ref: http://sources.redhat.com/ml/gdb-patches/2003-03/msg00617.html

-- 
Joel