* [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-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
* 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
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).