Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
* gdb : strstr prototype
@ 1999-04-13 16:43 Philippe De Muyter
  1999-04-13 16:29 ` Philippe De Muyter
  0 siblings, 1 reply; 2+ messages in thread
From: Philippe De Muyter @ 1999-04-13 16:43 UTC (permalink / raw)
  To: gdb-patches

Wed Apr 14 01:18:37 1999  Philippe De Muyter  <phdm@macqel.be>

	* configure.in (BFD_NEED_DECLARATION): Check also for strstr.
	* acconfig.h (NEED_DECLARATION_MALLOC): Define slot removed; it is
	now generated automatically.
	(NEED_DECLARATION_REALLOC, NEED_DECLARATION_FREE): Ditto.
	(NEED_DECLARATION_STRERROR): Ditto.
	* gdb_string.h (strstr): Provide function prototype if
	NEED_DECLARATION_STRSTR.

--- ./gdb/acconfig.h	Wed Apr 14 01:21:58 1999
+++ ./gdb/acconfig.h	Tue Apr 13 20:02:59 1999
@@ -1,15 +1,3 @@
-
-/* Whether malloc must be declared even if <stdlib.h> is included.  */
-#undef NEED_DECLARATION_MALLOC
-
-/* Whether realloc must be declared even if <stdlib.h> is included.  */
-#undef NEED_DECLARATION_REALLOC
-
-/* Whether free must be declared even if <stdlib.h> is included.  */
-#undef NEED_DECLARATION_FREE
-
-/* Whether strerror must be declared even if <string.h> is included.  */
-#undef NEED_DECLARATION_STRERROR
 @TOP@
 
 /* Define if pstatus_t type is available */
--- ./gdb/gdb_string.h	Wed Apr 14 01:21:59 1999
+++ ./gdb/gdb_string.h	Tue Apr 13 19:50:02 1999
@@ -37,10 +37,6 @@
 extern char *strrchr PARAMS ((const char *, int));	/* X3.159-1989  4.11.5.5 */
 #endif
 
-#ifndef strstr
-extern char *strstr PARAMS ((const char *, const char *));	/* X3.159-1989  4.11.5.7 */
-#endif
-
 #ifndef strtok
 extern char *strtok PARAMS ((char *, const char *));	/* X3.159-1989  4.11.5.8 */
 #endif
@@ -63,6 +59,12 @@
 
 #ifdef NEED_DECLARATION_STRDUP
 extern char *strdup (); /* full prototype collides w/ some OSes (AIX 3.2.5) */
+#endif
+
+#ifdef NEED_DECLARATION_STRSTR
+#ifndef strstr
+extern char *strstr PARAMS ((const char *, const char *));	/* X3.159-1989  4.11.5.7 */
+#endif
 #endif
 
 #endif	/* !defined(GDB_STRING_H) */
--- ./gdb/configure.in	Wed Apr 14 01:21:59 1999
+++ ./gdb/configure.in	Tue Apr 13 19:52:09 1999
@@ -82,6 +82,7 @@ BFD_NEED_DECLARATION(realloc)
 BFD_NEED_DECLARATION(free)
 BFD_NEED_DECLARATION(strerror)
 BFD_NEED_DECLARATION(strdup)
+BFD_NEED_DECLARATION(strstr)
 
 
 # The following save_state_t checkery is only necessary for HPUX 
From toddpw@wrs.com Tue Apr 13 21:52:00 1999
From: toddpw@wrs.com (Todd Whitesel)
To: gdb-patches@cygnus.com
Subject: Re: `step'-like commands in breakpoint commands list
Date: Tue, 13 Apr 1999 21:52:00 -0000
Message-id: <199904140410.VAA11189@alabama.wrs.com>
References: <199904122248.AAA31605@mail.macqel.be>
X-SW-Source: 1999-04/msg00022.html
Content-length: 1340

> On m68k-motorola-sysv and on powerpc-ibm-aix4.1.5.0, with gdb-4.17.87,
> the testsuite fails at `continue in infrun_breakpoint_command_test', because
> the breakpoint commands list is only executed up to the first `step' command.
> The patch below fixes that.
...
> +#if 0 /* FIXME : Disabled 1999-04-12 by phdm@macqel.be, to allow `step',
> +	 `next', `finish', etc. to work in breakpoint commands list.  As
> +	 this is the only instruction that sets `breakpoint_proceeded',
> +	 all the `breakpoint_proceeded'-related stuff could also be removed.
> +	 */
>    breakpoint_proceeded = 1;	/* We're about to proceed... */
> +#endif

Is this patch safe?? What about the comment further down:

	/* The inferior is proceeded by the command; bomb out now.
	   The bpstat chain has been blown away by wait_for_inferior.
	   But since execution has stopped again, there is a new bpstat
	   to look at, so start over.  */

I should also note that due to the recursive implementation of
bpstat_do_actions(), it is probably not a good idea to allow
bpstat_do_action() calls to accumulate on the stack if the inferior
keeps hitting breakpoints that have command lists. Also, when you
request a Quit, then GDB forgets all that breakpoint command list
state, and behaves differently when you continue the inferior.

-- 
Todd Whitesel
toddpw @ wrs.com
From ac131313@cygnus.com Tue Apr 13 23:29:00 1999
From: Andrew Cagney <ac131313@cygnus.com>
To: gdb-patches@cygnus.com, Stan Shebs <shebs@cygnus.com>
Subject: Re: support for ARM GNU/Linux
Date: Tue, 13 Apr 1999 23:29:00 -0000
Message-id: <37142B16.B43B5200@cygnus.com>
References: <np90bx1a3v.fsf@zwingli.cygnus.com> <E10X3Uv-0003Kd-00.cygnus.patches.gdb@fountain.nexus.co.uk>
X-SW-Source: 1999-04/msg00023.html
Content-length: 4104

Philip Blundell wrote:
> 
> In message < np90bx1a3v.fsf@zwingli.cygnus.com >, Jim Blandy writes:
> >Could you adapt your patches to 4.18?  If I try to do it and anything
> >non-trivial comes up, I'd almost certainly screw them up.
> >
> >Could you rename the native file armlinux-nat.c?  "lnx" looks like
> >"lynx", which is something else entirely...  :)
> 
> Sure.  I've appended here a new patch incorporating those changes.  It's
> against the 19990412 snapshot.

Hello,


I'm afraid that you've drawn the short straw - the way targets are
implemented is changing.  In fact, one change I refer to below won't be
visible until the *next* snapshot.

The unfortunate consequence is that there is going to need to be more
work before this change can be integrated into GDB proper.  On the
bright side, if you bare with me, we will have greatly simplified the
task of evolving the ARM GDB into a debugger that can support several
different architectures.


--


The file gdb/armlinux-tdep.c will need tidying.  Check the Gnu
Programming Standars document -
http://www.fsf.org/prep/standards_toc.html .  It would be good to get
any new files correctly formatted from day one (even if all the old ones
are still a mess :-).


--


You've used the *_BREAKPOINT macro's.  In the process, the change:

	Tue Nov 24 14:13:10 1998  Andrew Cagney  <cagney@chook>

	* config/arm/tm-arm.h ({BIG,LITTLE}_BREAKPOINT): Delete macros.
 	({ARM,THUMB}_{BE,LE}_BREAKPOINT): Move macros from here.
	* arm-tdep.c: To here.

was reversed.  The use of the *_BREAKPOINT macros is going to be
discouraged.  Instead you are encouraged to use a function, called via
the macro BREAKPOINT_FROM_PC() (ref gdbint.texinfo).  In the case of the
ARM, BREAKPOINT_FROM_PC() maps onto the function
arm_breakpoint_from_pc().  That function should be coded so that it can
determine the required breakpoint without having to revert to compile
time CPP directives such as #undef, #define or #if.

If you feal that a new implementation of the breakpoint_from_pc()
function (armlinux_breakpoint_from_pc() say) is needed, I would suggest
defining BREAKPOINT_FROM_PC as a global function pointer and initialize
that pointer in __initialize_arm_tdep().  The existing
arm_breakpoint_from_pc() function should not be #ifdef'd out.

In the future that global can be be made part of an architecture object
(``struct gdbarch'' say).


--


The file gdb/config/arm/tm-linux.h #defines OS_BKPT_SWI.  That is in
turn used by the ARM version of CALL_DUMMY.  CALL_DUMMY has just been
replaced with CALL_DUMMY_WORDS and SIZEOF_CALL_DUMMY_WORDS (see
gdb/doc/gdbint.texi in the *next* snapshot).  Rather than define
OS_BKPT_SWI could I strongly encourage you to instead use these new
macros.  Like for BREAKPOINT_FROM_PC, I would suggest using a global
initialized from __initialize_arm_tdep().


--


I'm slightly curious about what is going on with all these different
breakpoints (I should hasten to point out that I'm _not_ the ARM
expert/maintainer :-).  Stan Shebs recently commited the change:

	1999-03-02  Stan Shebs  <shebs@andros.cygnus.com>

	From Gary Thomas  <gthomas@cygnus.co.uk>:
	* arm-tdep.c (ARM_LE_BREAKPOINT, ARM_BE_BREAKPOINT,
	THUMB_LE_BREAKPOINT, THUMB_BE_BREAKPOINT): Use illegal instruction
	instead of SWI 24.
	* config/arm/tm-arm.h (CALL_DUMMY): Ditto.
	(IN_SIGTRAMP): Define.

Originally they were:

 ARM_LE_BREAKPOINT {0x00,0x00,0x18,0xef} /* BKPT_SWI from <sys/ptrace.h
*/
 ARM_BE_BREAKPOINT {0xef,0x18,0x00,0x00} /* BKPT_SWI from <sys/ptrace.h
*/

While Stan changed them to:

 ARM_LE_BREAKPOINT {0xFE,0xDE,0xFF,0xE7} /* Recognized illegal opcodes
*/
 ARM_BE_BREAKPOINT {0xE7,0xFF,0xDE,0xFE}

And now, in your patch there is:

 ARM_LE_BREAKPOINT        {0x01,0x00,0x9f,0xef}         /* swi 0x9f0001
*/
 ARM_BE_BREAKPOINT        {0xef,0x9f,0x00,0x01}

I'm just kind of wondering which/any are needed :-) There must be a
standard somewhere ;-)

Could I suggest including a comment explaining where your breakpoint
instructions come from.  If it is part of the LINUX/ARM environment then
make a reference to that.


	enjoy,
		Andrew
From ac131313@cygnus.com Wed Apr 14 01:06:00 1999
From: Andrew Cagney <ac131313@cygnus.com>
To: gdb-patches@cygnus.com
Subject: Re: support for ARM GNU/Linux
Date: Wed, 14 Apr 1999 01:06:00 -0000
Message-id: <37143C2A.9340FF5B@cygnus.com>
References: <np90bx1a3v.fsf@zwingli.cygnus.com> <37142B16.B43B5200.cygnus.patches.gdb@cygnus.com>
X-SW-Source: 1999-04/msg00024.html
Content-length: 1209

Andrew Cagney wrote:

> The file gdb/config/arm/tm-linux.h #defines OS_BKPT_SWI.  That is in
> turn used by the ARM version of CALL_DUMMY.  CALL_DUMMY has just been
> replaced with CALL_DUMMY_WORDS and SIZEOF_CALL_DUMMY_WORDS (see
> gdb/doc/gdbint.texi in the *next* snapshot).  Rather than define
> OS_BKPT_SWI could I strongly encourage you to instead use these new
> macros.  Like for BREAKPOINT_FROM_PC, I would suggest using a global
> initialized from __initialize_arm_tdep().

FYI,

Below is the relevant section of the internals manual.

	Andrew



@item CALL_DUMMY_P
A C expresson that is non-zero when the target suports inferior function
calls.
 
@item CALL_DUMMY_WORDS
Pointer to an array of @var{LONGEST} words of data containing
host-byte-ordered @var{REGISTER_BYTES} sized values that partially
specify the sequence of instructions needed for an inferior function
call.
 
Should be deprecated in favour of a macro that uses target-byte-ordered
data.
 
@item SIZEOF_CALL_DUMMY_WORDS
The size of @var{CALL_DUMMY_WORDS}.  When @var{CALL_DUMMY_P} this must
return a positive value.  See also @var{CALL_DUMMY_LENGTH}.
 
@item CALL_DUMMY
A static initializer for @var{CALL_DUMMY_WORDS}.  Deprecated.
From pb@nexus.co.uk Wed Apr 14 03:34:00 1999
From: Philip Blundell <pb@nexus.co.uk>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: gdb-patches@cygnus.com
Subject: Re: support for ARM GNU/Linux 
Date: Wed, 14 Apr 1999 03:34:00 -0000
Message-id: <E10XLr3-0001eA-00@fountain.nexus.co.uk>
References: <37142B16.B43B5200@cygnus.com>
X-SW-Source: 1999-04/msg00025.html
Content-length: 1156

>I'm slightly curious about what is going on with all these different
>breakpoints (I should hasten to point out that I'm _not_ the ARM
>expert/maintainer :-).  Stan Shebs recently commited the change:

Under Linux/ARM (and I think RISC iX, which is probably where the original 
breakpoint definitions came from) the traditional way to perform a breakpoint 
is to execute a particular SWI.  The kernel will then stop the inferior 
process with SIGTRAP and wake the debugger.  For systems where there is no 
explicit OS support for breakpoints, the set of opcodes that Stan put in 
will provoke a CPU "undefined instruction" exception which again stops the 
process.  Plus of course there's an equivalent set for Thumb.

I think all of these are needed for their respective target systems.  The RISC 
iX support probably wants splitting out into its own file anyway; at the 
moment it's hiding away in various files that are named as if they contain 
only ARM generic code.

>Could I suggest including a comment explaining where your breakpoint
>instructions come from.  If it is part of the LINUX/ARM environment then
>make a reference to that.

OK.

p.



^ permalink raw reply	[flat|nested] 2+ messages in thread
end of thread, other threads:[~1999-04-13 16:43 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-04-13 16:43 gdb : strstr prototype Philippe De Muyter
1999-04-13 16:29 ` Philippe De Muyter

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox