From: Richard Earnshaw <rearnsha@arm.com>
To: Pierre Muller <muller@cerbere.u-strasbg.fr>
Cc: gdb-patches@sources.redhat.com, Richard.Earnshaw@arm.com
Subject: Re: PATCH multi-arch GET_LONGJMP_TARGET
Date: Tue, 19 Feb 2002 02:42:00 -0000 [thread overview]
Message-ID: <200202191041.KAA18603@cam-mail2.cambridge.arm.com> (raw)
In-Reply-To: Your message of "Tue, 19 Feb 2002 10:13:54 GMT." <200202191013.KAA15886@cam-mail2.cambridge.arm.com>
[-- Attachment #1: Type: text/plain, Size: 1467 bytes --]
> >
> > This patch makes that
> > GET_LONGJMP_TARGET is always defined for all mutiarched target
> > (even partial !).
> >
> > Thus it breaks compilation of Cygwin native GDB,
> > because JB_PC and JB_ELEMENT_SIZE are not defined for these targets.
> > (and several other i386 targets)
> >
> > The correct fix would be to add these values to gdbarch ...
> >
> > The following was committed as an obvious fix.
>
> Ah, sorry about that.
>
> Perhaps it would also be sensible to check GET_LONGJMP_TARGET_P() in that
> code and always return 0 if it is false.
>
> I'll go around the other tdep files and clean those up as well.
>
> R.
>
Thinking about it, the cleanest way to handle this for now is to change
the test for a definition of JB_PC, since unless that is defined the code
won't compile, and even if it did it would give the wrong answer.
As far as I can tell, apart from i386, only two further ports define
GET_LONGJMP_TARGET: arc and sparc. Arc seems never to use the code
(there's only one .h file for that port and it doesn't define
GET_LONGJMP_TARGET or JB_PC); Sparc seems to define it for pretty much all
configurations I can think of.
Anyone object to the following patch? I'll leave the x86 code as is for
now, since you've already fixed that.
R.
<date> Richard Earnshaw <rearnsha@arm.com>
* arc-tdep.c (get_longjmp_target): Only compile this function if
JB_PC is defined.
* sparc-tdep.c (get_longjmp_target): Likewise.
[-- Attachment #2: gdb-jbpc.patch --]
[-- Type: text/x-patch , Size: 1918 bytes --]
Index: arc-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/arc-tdep.c,v
retrieving revision 1.8
diff -p -r1.8 arc-tdep.c
*** arc-tdep.c 2002/02/05 04:37:21 1.8
--- arc-tdep.c 2002/02/19 10:35:26
*************** arc_software_single_step (enum target_si
*** 571,577 ****
}
}
\f
! #ifdef GET_LONGJMP_TARGET
/* Figure out where the longjmp will land. Slurp the args out of the stack.
We expect the first arg to be a pointer to the jmp_buf structure from which
we extract the pc (JB_PC) that we will land at. The pc is copied into PC.
--- 571,579 ----
}
}
\f
! /* Because of Multi-arch, GET_LONGJMP_TARGET is always defined. So test
! for a definition of JB_PC. */
! #ifdef JB_PC
/* Figure out where the longjmp will land. Slurp the args out of the stack.
We expect the first arg to be a pointer to the jmp_buf structure from which
we extract the pc (JB_PC) that we will land at. The pc is copied into PC.
Index: sparc-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/sparc-tdep.c,v
retrieving revision 1.22
diff -p -r1.22 sparc-tdep.c
*** sparc-tdep.c 2002/01/20 19:26:48 1.22
--- sparc-tdep.c 2002/02/19 10:35:26
*************** fill_fpregset (gdb_fpregset_t *fpregsetp
*** 1686,1693 ****
#endif /* USE_PROC_FS */
!
! #ifdef GET_LONGJMP_TARGET
/* Figure out where the longjmp will land. We expect that we have just entered
longjmp and haven't yet setup the stack frame, so the args are still in the
--- 1686,1694 ----
#endif /* USE_PROC_FS */
! /* Because of Multi-arch, GET_LONGJMP_TARGET is always defined. So test
! for a definition of JB_PC. */
! #ifdef JB_PC
/* Figure out where the longjmp will land. We expect that we have just entered
longjmp and haven't yet setup the stack frame, so the args are still in the
next prev parent reply other threads:[~2002-02-19 10:42 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-02-18 5:38 Richard Earnshaw
2002-02-19 0:48 ` Pierre Muller
2002-02-19 2:14 ` Richard Earnshaw
2002-02-19 2:42 ` Richard Earnshaw [this message]
2002-02-20 2:49 ` Richard Earnshaw
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200202191041.KAA18603@cam-mail2.cambridge.arm.com \
--to=rearnsha@arm.com \
--cc=Richard.Earnshaw@arm.com \
--cc=gdb-patches@sources.redhat.com \
--cc=muller@cerbere.u-strasbg.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox