Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
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

  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