* [6] What if EXTRA_FRAME_INFO wasn't required @ 2003-03-28 21:34 Andrew Cagney 2003-03-28 21:39 ` Joel Brobecker 2003-03-31 22:24 ` Joel Brobecker 0 siblings, 2 replies; 8+ messages in thread From: Andrew Cagney @ 2003-03-28 21:34 UTC (permalink / raw) To: Joel Brobecker, gdb 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [6] What if EXTRA_FRAME_INFO wasn't required 2003-03-28 21:34 [6] What if EXTRA_FRAME_INFO wasn't required Andrew Cagney @ 2003-03-28 21:39 ` Joel Brobecker 2003-03-31 0:18 ` Andrew Cagney 2003-03-31 22:24 ` Joel Brobecker 1 sibling, 1 reply; 8+ messages in thread From: Joel Brobecker @ 2003-03-28 21:39 UTC (permalink / raw) To: Andrew Cagney; +Cc: gdb > 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) ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [6] What if EXTRA_FRAME_INFO wasn't required 2003-03-28 21:39 ` Joel Brobecker @ 2003-03-31 0:18 ` Andrew Cagney 2003-03-31 22:32 ` Joel Brobecker 0 siblings, 1 reply; 8+ messages in thread From: Andrew Cagney @ 2003-03-31 0:18 UTC (permalink / raw) To: Joel Brobecker; +Cc: gdb [-- 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 */ ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [6] What if EXTRA_FRAME_INFO wasn't required 2003-03-31 0:18 ` Andrew Cagney @ 2003-03-31 22:32 ` Joel Brobecker 2003-03-31 23:36 ` Andrew Cagney 2003-04-08 22:08 ` Andrew Cagney 0 siblings, 2 replies; 8+ messages in thread From: Joel Brobecker @ 2003-03-31 22:32 UTC (permalink / raw) To: Andrew Cagney; +Cc: gdb > 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [6] What if EXTRA_FRAME_INFO wasn't required 2003-03-31 22:32 ` Joel Brobecker @ 2003-03-31 23:36 ` Andrew Cagney 2003-04-08 22:08 ` Andrew Cagney 1 sibling, 0 replies; 8+ messages in thread From: Andrew Cagney @ 2003-03-31 23:36 UTC (permalink / raw) To: Joel Brobecker; +Cc: gdb > 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [6] What if EXTRA_FRAME_INFO wasn't required 2003-03-31 22:32 ` Joel Brobecker 2003-03-31 23:36 ` Andrew Cagney @ 2003-04-08 22:08 ` Andrew Cagney 2003-04-08 22:17 ` Joel Brobecker 1 sibling, 1 reply; 8+ messages in thread From: Andrew Cagney @ 2003-04-08 22:08 UTC (permalink / raw) To: Joel Brobecker; +Cc: gdb > > 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [6] What if EXTRA_FRAME_INFO wasn't required 2003-04-08 22:08 ` Andrew Cagney @ 2003-04-08 22:17 ` Joel Brobecker 0 siblings, 0 replies; 8+ messages in thread From: Joel Brobecker @ 2003-04-08 22:17 UTC (permalink / raw) To: Andrew Cagney; +Cc: gdb > 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [6] What if EXTRA_FRAME_INFO wasn't required 2003-03-28 21:34 [6] What if EXTRA_FRAME_INFO wasn't required Andrew Cagney 2003-03-28 21:39 ` Joel Brobecker @ 2003-03-31 22:24 ` Joel Brobecker 1 sibling, 0 replies; 8+ messages in thread From: Joel Brobecker @ 2003-03-31 22:24 UTC (permalink / raw) To: Andrew Cagney; +Cc: gdb 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2003-04-08 22:17 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-03-28 21:34 [6] What if EXTRA_FRAME_INFO wasn't required Andrew Cagney 2003-03-28 21:39 ` Joel Brobecker 2003-03-31 0:18 ` Andrew Cagney 2003-03-31 22:32 ` Joel Brobecker 2003-03-31 23:36 ` Andrew Cagney 2003-04-08 22:08 ` Andrew Cagney 2003-04-08 22:17 ` Joel Brobecker 2003-03-31 22:24 ` Joel Brobecker
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).