Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
* [RFA]: DejaGNU support for 68HC11/68HC12
@ 2001-05-20  4:44 Stephane Carrez
  2001-05-21  8:44 ` [DejaGnu] " Rob Savoye
  0 siblings, 1 reply; 4+ messages in thread
From: Stephane Carrez @ 2001-05-20  4:44 UTC (permalink / raw)
  To: dejagnu, gdb-patches

Hi!

I would like to add the following files in DejaGNU for the configuration
of 68HC11/68HC12 gcc,gdb validation.  I've been using them for a while now
for gcc 2.95 and gdb 5.0 validation.  I have a copyright assignment for DejaGNU.

Can you approve this patch for both GDB and DejaGNU?

Thanks,
	Stephane

2001-05-20  Stephane Carrez  <Stephane.Carrez@worldnet.fr>

	* baseboards/m68hc11-sim.exp: New file for 68HC11/68HC12 validation.
	* config/m68hc11.exp: New file.
Index: config/m68hc11.exp
===================================================================
RCS file: m68hc11.exp
diff -N m68hc11.exp
--- /dev/null	Tue May  5 13:32:27 1998
+++ m68hc11.exp	Sun May 20 04:27:25 2001
@@ -0,0 +1,20 @@
+#   Copyright (C) 2001 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+# 
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+# 
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  
+
+# Please email any bugs, comments, and/or additions to this file to:
+# DejaGnu@cygnus.com
+
+load_generic_config "gdb-comm";
Index: baseboards/m68hc11-sim.exp
===================================================================
RCS file: m68hc11-sim.exp
diff -N m68hc11-sim.exp
--- /dev/null	Tue May  5 13:32:27 1998
+++ m68hc11-sim.exp	Sun May 20 04:27:25 2001
@@ -0,0 +1,71 @@
+# This is a list of toolchains that are supported on this board.
+set_board_info target_install  {m6811-elf}
+
+# Load the generic configuration for this board. This will define any
+# routines needed to communicate with the board.
+load_generic_config "sim";
+
+# basic-sim.exp is a basic description for the standard Cygnus simulator.
+load_base_board_description "basic-sim"
+
+# The name of the simulator directory is "m68hc11".
+setup_sim m68hc11
+
+# The compiler used to build for this board. This has *nothing* to do
+# with what compiler is tested if we're testing gcc.
+set_board_info compiler  "[find_gcc]"
+
+# We only support newlib on this target. We assume that all multilib
+# options have been specified before we get here.
+set_board_info cflags "[libgloss_include_flags] [newlib_include_flags]";
+
+# The GCC testsuite programs create quite large executables for the 68HC11.
+# We have to give enough room for the text section and we must make sure
+# that the data section does not overlay the 68HC11 IO registers. We could
+# relocate the IO registers but this would add some complexity to the crt0.
+set_board_info ldflags "[libgloss_link_flags] [newlib_link_flags] -Wl,-Ttext,0x2000 -Wl,-Tdata,0x1100";
+# No linker script needed.
+set_board_info ldscript "-Wl,--script,sim-valid.x";
+
+# Can't pass arguments to programs on this target..
+set_board_info noargs  1
+# And there's no support for signals.
+set_board_info gdb,nosignals  1
+set_board_info gdb,skip_float_tests 1
+set_board_info gdb,nomalloc 1
+set_board_info gdb,nointerrupts 1
+# Don't do inferiorio
+#set_board_info gdb,noinferiorio 1
+
+# Data section is not installed by loading the program.  The data
+# section is installed at run time by the crt0 (copied from text/ROM
+# to RAM).
+set_board_info gdb,noloaddata 1
+
+# printf does not support %f, don't execute gdb tests that rely on this.
+set_board_info gdb,skip_float_tests 1
+
+# Disable the 68HC11 EEPROM to avoid problems with GCC testsuite
+# programs and map them in 0x8000..0xffff.
+set_board_info sim,options "--cpu-config=0xe"
+
+# Used by a few gcc.c-torture testcases to delimit how large the stack can
+# be.
+set_board_info gcc,stack_size  1024
+
+# Used by a few gcc.c-torture testcases when varargs are used (stdarg is ok).
+set_board_info gcc,no_varargs  1
+
+# Torture test gcc.c-torture/execute/920501-6.c takes about 300 seconds on a
+# 700 Mhz Pentium, so up the time limit.
+set board_info($board,sim_time_limit) 400
+
+set_board_info mathlib ""
+
+# The first -lbcc is here to get the small implementation of printf.
+# The second -lbcc provides the system calls (write, read) used in -lc.
+# The last -lc defines the __errno used in -lbcc.
+set_board_info libs "-lbcc -lc -lgcc -lc -lbcc"
+
+# sizeof int != sizeof long.
+set_board_info gdb,short_int 1
From Stephane.Carrez@worldnet.fr Sun May 20 04:46:00 2001
From: Stephane Carrez <Stephane.Carrez@worldnet.fr>
To: gdb-patches@sources.redhat.com
Subject: [RFA]: Fix gdb.base/remote for embedded targets (HC11)
Date: Sun, 20 May 2001 04:46:00 -0000
Message-id: <3B07AFCF.211DC3BF@worldnet.fr>
X-SW-Source: 2001-05/msg00365.html
Content-length: 4397

Hi!

The gdb.base/remote test fails for 68HC11/68HC12:

  - The gdb.base/remote.c defines a data table that is too large to link for
    68HC11 targets (it requires 48K of data).  

  - For HC11/HC12, the data section is installed by the crt0.  The data section
    has its image in ROM and it is copied to RAM by the startup code.  With a
    48K data table, it requires 96K of memory (48K rom, 48K ram).

    After the load, the data table is not initialized.  It is initialized when
    we reached the 'main'.

The following patch improves the gdb.base/remote test:

  - The remote.c data table is reduced to 1K for 68HC11 (only), and the
    test verifies only the 1K load for 68HC11 (other platforms still use 48K).

  - It checks for a new 'gdb,noloaddata' configuration variable and
    runs to the main before verifying the load.

Can you approve this patch?

Thanks,
	Stephane

2001-05-20  Stephane Carrez  <Stephane.Carrez@worldnet.fr>

	* gdb.base/remote.c (RANDOM_DATA_SIZE): New define, defaults to 48K 
	and defined to 1K for m68hc11.
	(random_data): Reduce table to 1K for embedded platforms (68hc11).
	* gdb.base/remote.exp (remote_data_size): New variable to tell the size
	of the data table; don't test past this size; check for gdb,noloaddata
	and run to the main if it is set (data section installed by crt0).
Index: testsuite/gdb.base/remote.c
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.base/remote.c,v
retrieving revision 1.1.1.2
diff -u -p -r1.1.1.2 remote.c
--- remote.c	1999/12/07 03:56:16	1.1.1.2
+++ remote.c	2001/05/20 11:40:00
@@ -23,12 +23,21 @@ BEGIN {
 
 */
 
+#ifdef mc68hc11
+# define RANDOM_DATA_SIZE (1024)
+#endif
+
 /* Use a character buffer to avoid byte order problems. 48k is
    chosen so that the buffer required at least 3 16k packets but
    targets often have no more than 64k of data. */
 /* If you change this data, you will also have to change the checks
    for the data in remote.c */
-unsigned char random_data[3 * 2048 * 8] = {
+#ifndef RANDOM_DATA_SIZE
+# define RANDOM_DATA_SIZE (3 * 2048 * 8)
+# define BIG_RANDOM_DATA
+#endif
+
+unsigned char random_data[RANDOM_DATA_SIZE] = {
   60,  74, 216,  38, 149,  49, 207,  44,
  124,  38,  93, 125, 232,  67, 228,  56,
  161, 146,  85,  26, 128, 145, 218,  10,
@@ -157,6 +166,7 @@ unsigned char random_data[3 * 2048 * 8] 
  196,  13, 161, 122, 145, 141, 102, 233,
  227, 112, 121,  67, 111, 148, 160,  32,
  199, 117, 223, 105, 184, 131, 119, 182,
+#ifdef BIG_RANDOM_DATA
   60,  26, 169, 194, 173, 164, 249, 135,
  178,  57,  50,  44,  12, 159, 167, 240,
  249, 188,  86, 192,  73,  47,  74,  77,
@@ -6173,6 +6183,7 @@ unsigned char random_data[3 * 2048 * 8] 
   97, 106, 152,  12, 243, 240,  41, 251,
   35, 249, 105, 228,  53,  94,  43, 119,
   61, 162, 192,  78,  58,  46,  84, 110,
+#endif
 };
 
 int
Index: testsuite/gdb.base/remote.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.base/remote.exp,v
retrieving revision 1.2
diff -u -p -r1.2 remote.exp
--- remote.exp	2001/03/06 08:21:51	1.2
+++ remote.exp	2001/05/20 11:40:02
@@ -30,6 +30,12 @@ if {! [is_remote target]} {
     return
 }
 
+# configure the size of the data table to check according to the target
+if { [istarget "m6811-*-*"] } then {
+   set remote_data_size 1024
+} else {
+   set remote_data_size 49152
+}
 
 set testfile "remote"
 set srcfile ${testfile}.c
@@ -138,11 +144,16 @@ gdb_load_timed $binfile 0 "fixed" 16385
 # fall back to the default
 gdb_load_timed $binfile 0 "limit" 0
 
-
 #
 # Part THREE: Check the upload behavour
 #
 
+if [target_info exists gdb,noloaddata] then {
+    if ![runto_main] then {
+	fail "Cannot run to main"
+    }
+}
+
 # Carefully check memory around each of the most common packet edge
 # conditions
 
@@ -152,9 +163,10 @@ gdb_test "x/8ub random_data" \
 gdb_test "x/8ub random_data + 400 - 4" \
 	"<random_data\\+396>:\[ \t\]+185\[ \t\]+255\[ \t\]+50\[ \t\]+140\[ \t\]+237\[ \t\]+172\[ \t\]+143\[ \t\]+93"
 
-gdb_test "x/8ub random_data + 16384 - 4" \
+if {$remote_data_size > 16380 } then {
+    gdb_test "x/8ub random_data + 16384 - 4" \
 	"<random_data\\+16380>:\[ \t\]+178\[ \t\]+180\[ \t\]+135\[ \t\]+93\[ \t\]+70\[ \t\]+62\[ \t\]+205\[ \t\]+76"
-
+}
 
 # Read a chunk just larger than the packet size (reduce the packet
 # size to make life easier)
From Stephane.Carrez@worldnet.fr Sun May 20 04:48:00 2001
From: Stephane Carrez <Stephane.Carrez@worldnet.fr>
To: gdb-patches@sources.redhat.com
Subject: [RFA]: Fix gdb.base/callfwmall.exp for platforms without malloc
Date: Sun, 20 May 2001 04:48:00 -0000
Message-id: <3B07B042.6BAD93A0@worldnet.fr>
X-SW-Source: 2001-05/msg00366.html
Content-length: 3770

Hi!

The test gdb.base/callfwmall.exp checks for the GDB ability to
'call/print' a function of the inferior.  Several print commands
require the program to have 'malloc' so that GDB allocates a string
for input parameters.  The 'callfwmall.c' file does not have any
reference to malloc, which means that the final executable may not
have it.  This is my case for HC11.  This means that the test fails
with:

 (gdb) FAIL: gdb.base/callfwmall.exp: p t_string_values("string 1","string 2")
p t_string_values("string 1",string_val2)
evaluation of this expression requires the program to have a function "malloc".

The following patch uses a new 'gdb,nomalloc' configuration variable
to check whether these 't_string_values' tests can be made or not.

Can you approve this patch?

	Stephane

2001-05-20  Stephane Carrez  <Stephane.Carrez@worldnet.fr>

	* gdb.base/callfwmall.exp (do_function_calls): Check for gdb,nomalloc
	and don't execute the tests that require the program to have malloc.
Index: testsuite/gdb.base/callfwmall.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.base/callfwmall.exp,v
retrieving revision 1.2
diff -u -p -r1.2 callfwmall.exp
--- callfwmall.exp	2001/03/06 08:21:50	1.2
+++ callfwmall.exp	2001/05/20 11:39:27
@@ -167,18 +167,24 @@ proc do_function_calls {} {
    
     }
 
-    gdb_test "p t_string_values(string_val2,string_val1)" " = 0"
-    gdb_test "p t_string_values(string_val1,string_val2)" " = 1"
-    gdb_test "p t_string_values(\"string 1\",\"string 2\")" " = 1"
-    gdb_test "p t_string_values(\"string 1\",string_val2)" " = 1"
-    gdb_test "p t_string_values(string_val1,\"string 2\")" " = 1"
-
+    # Calling a function with a string as parameter requires the
+    # program to provide malloc().  The string is allocated in
+    # malloc area (and... by the way never freed!!!).
+    # Don't execute this test on platforms that don't provide malloc.
+    if ![target_info exists gdb,nomalloc] {
+	gdb_test "p t_string_values(string_val2,string_val1)" " = 0"
+	gdb_test "p t_string_values(string_val1,string_val2)" " = 1"
+	gdb_test "p t_string_values(\"string 1\",\"string 2\")" " = 1"
+	gdb_test "p t_string_values(\"string 1\",string_val2)" " = 1"
+	gdb_test "p t_string_values(string_val1,\"string 2\")" " = 1"
+    }
     gdb_test "p t_char_array_values(char_array_val2,char_array_val1)" " = 0"
     gdb_test "p t_char_array_values(char_array_val1,char_array_val2)" " = 1"
-    gdb_test "p t_char_array_values(\"carray 1\",\"carray 2\")" " = 1"
-    gdb_test "p t_char_array_values(\"carray 1\",char_array_val2)" " = 1"
-    gdb_test "p t_char_array_values(char_array_val1,\"carray 2\")" " = 1"
-
+    if ![target_info exists gdb,nomalloc] {
+	gdb_test "p t_char_array_values(\"carray 1\",\"carray 2\")" " = 1"
+	gdb_test "p t_char_array_values(\"carray 1\",char_array_val2)" " = 1"
+	gdb_test "p t_char_array_values(char_array_val1,\"carray 2\")" " = 1"
+    }
     gdb_test "p doubleit(4)" " = 8"
     gdb_test "p add(4,5)" " = 9"
     gdb_test "p t_func_values(func_val2,func_val1)" " = 0"
@@ -222,10 +228,12 @@ proc do_function_calls {} {
     gdb_test "p t_enum_value2(enum_val2)" " = 1"
     gdb_test "p t_enum_value2(enum_val1)" " = 0"
 
-    gdb_test "p sum_args(1,{2})" " = 2"
-    gdb_test "p sum_args(2,{2,3})" " = 5"
-    gdb_test "p sum_args(3,{2,3,4})" " = 9"
-    gdb_test "p sum_args(4,{2,3,4,5})" " = 14"
+    if ![target_info exists gdb,nomalloc] {
+	gdb_test "p sum_args(1,{2})" " = 2"
+	gdb_test "p sum_args(2,{2,3})" " = 5"
+	gdb_test "p sum_args(3,{2,3,4})" " = 9"
+	gdb_test "p sum_args(4,{2,3,4,5})" " = 14"
+    }
     gdb_test "p sum10 (1, 2, 3, 4, 5, 6, 7, 8, 9, 10)" " = 55"
 
     gdb_test "p t_structs_c(struct_val1)" "= 120 'x'" \
From Stephane.Carrez@worldnet.fr Sun May 20 04:49:00 2001
From: Stephane Carrez <Stephane.Carrez@worldnet.fr>
To: gdb-patches@sources.redhat.com
Subject: [RFA]: Fix gdb.base/long_long.exp for targets with 2-byte pointers 
Date: Sun, 20 May 2001 04:49:00 -0000
Message-id: <3B07B07A.9D5B4987@worldnet.fr>
X-SW-Source: 2001-05/msg00367.html
Content-length: 3891

Hi!

The gdb.base/long_long.exp validation uses p/a commands.  In the output,
it assumes the pointers are at least 4-bytes.  It fails on HC11 because
pointers are only 2-byte long.

In the patch, I propose to check the size of the pointer and check the
output of the p/a commands accordingly.

Can you approve this patch?

	Stephane

2001-05-20  Stephane Carrez  <Stephane.Carrez@worldnet.fr>

	* gdb.base/long_long.exp: Detect size of pointer.  Take into
	account 2-byte pointers when testing for p/a results.
Index: testsuite/gdb.base/long_long.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.base/long_long.exp,v
retrieving revision 1.4
diff -u -p -r1.4 long_long.exp
--- long_long.exp	2001/03/08 21:09:22	1.4
+++ long_long.exp	2001/05/20 11:39:29
@@ -95,6 +95,16 @@ gdb_expect {
     default { }
 }
 
+# Detect targets with 2-byte pointers.
+
+set sizeof_ptr 4
+send_gdb "print sizeof(void*)\n"
+gdb_expect {
+    -re ".* = 2.*$gdb_prompt $" { set sizeof_ptr 2 }
+    -re ".*$gdb_prompt $" { }
+    default { }
+}
+
 gdb_test "n 4"   ".*38.*" "get to known place"
 
 # Check the hack for long long prints.
@@ -120,7 +130,11 @@ gdb_test "p/d oct" ".*-63999259854741684
 gdb_test "p/u oct" ".*12046818088235383159.*"
 gdb_test "p/o oct" ".*.*"
 gdb_test "p/t oct" ".*1010011100101110111001010011100101110111000001010011100101110111.*"
-gdb_test "p/a oct" ".*0x.*77053977.*"
+if { $sizeof_ptr == 2 } {
+  gdb_test "p/a oct" ".*0x.*3977.*"
+} else {
+  gdb_test "p/a oct" ".*0x.*77053977.*"
+}
 gdb_test "p/c oct" ".*'w'.*"
 
 if { $sizeof_double == 8 } {
@@ -156,7 +170,13 @@ if { $target_bigendian_p } {
 	gdb_test "p/u *(int *)&oct" ".*2804868409.*"
 	gdb_test "p/o *(int *)&oct" ".*024713562471.*"
 	gdb_test "p/t *(int *)&oct" ".*10100111001011101110010100111001.*"
-	gdb_test "p/a *(int *)&oct" ".*0xf*a72ee539.*"
+
+	if { $sizeof_ptr == 2 } {
+	    gdb_test "p/a *(int *)&oct" ".*0xe539.*"
+	} else {
+	    gdb_test "p/a *(int *)&oct" ".*0xf*a72ee539.*"
+	}
+
 	gdb_test "p/c *(int *)&oct" ".*57 '9'.*"
 	gdb_test "p/f *(int *)&oct" ".*-2.42716126e-15.*"
 
@@ -166,7 +186,12 @@ if { $target_bigendian_p } {
 	gdb_test "p/u *(int *)&oct" ".*42798.*"
 	gdb_test "p/o *(int *)&oct" ".*0123456.*"
 	gdb_test "p/t *(int *)&oct" ".*1010011100101110.*"
-	gdb_test "p/a *(int *)&oct" ".*0xffffa72e.*"
+
+	if { $sizeof_ptr == 2 } {
+	    gdb_test "p/a *(int *)&oct" ".*0xa72e.*"
+	} else {
+	    gdb_test "p/a *(int *)&oct" ".*0xffffa72e.*"
+	}
 	gdb_test "p/c *(int *)&oct" ".*46 '.'.*"
 	gdb_test "p/f *(int *)&oct" ".*-22738.*"
 
@@ -176,9 +201,17 @@ if { $target_bigendian_p } {
     gdb_test "p/u *(short *)&oct" ".*42798.*"
     gdb_test "p/o *(short *)&oct" ".*0123456.*"
     gdb_test "p/t *(short *)&oct" ".*1010011100101110.*"
-    gdb_test "p/a *(short *)&oct" ".*0xf*ffffa72e.*"
+    if { $sizeof_ptr == 2 } {
+        gdb_test "p/a *(short *)&oct" ".*0xa72e.*"
+    } else {
+        gdb_test "p/a *(short *)&oct" ".*0xf*ffffa72e.*"
+    }
     gdb_test "p/c *(short *)&oct" ".* 46 '.'.*"
-    gdb_test "p/a *(short *)&oct" ".*0xf*ffffa72e.*"
+    if { $sizeof_ptr == 2 } {
+        gdb_test "p/a *(short *)&oct" ".*0xa72e.*"
+    } else {
+        gdb_test "p/a *(short *)&oct" ".*0xf*ffffa72e.*"
+    }
     gdb_test "p/f *(short *)&oct" ".*-22738.*"
 
     gdb_test "x/x &oct" ".*0xa72ee539.*"
@@ -186,7 +219,11 @@ if { $target_bigendian_p } {
     gdb_test "x/u &oct" ".*2804868409.*"
     gdb_test "x/o &oct" ".*024713562471.*"
     gdb_test "x/t &oct" ".*10100111001011101110010100111001.*"
-    gdb_test "x/a &oct" ".*0xa72ee539.*"
+    if { $sizeof_ptr == 2 } {
+	gdb_test "x/a &oct" ".*0xa72e.*"
+    } else {
+	gdb_test "x/a &oct" ".*0xa72ee539.*"
+    }
     gdb_test "x/c &oct" ".*-89 .*"
     # FIXME GDB's output is correct, but this longer match fails.
     # gdb_test "x/c &oct" ".*-89 '\\\\247'.*"
From Stephane.Carrez@worldnet.fr Sun May 20 04:50:00 2001
From: Stephane Carrez <Stephane.Carrez@worldnet.fr>
To: gdb-patches@sources.redhat.com
Subject: [RFA]: Fix gdb.c++/userdef.exp for HC11
Date: Sun, 20 May 2001 04:50:00 -0000
Message-id: <3B07B0AC.59C50A0@worldnet.fr>
X-SW-Source: 2001-05/msg00368.html
Content-length: 1199

Hi!

The test gdb.c++/userdef.exp does not link for HC11 because there is
no C++ iostream.  The patch below avoids to execute the test for m6811 target.

Can you approve it?

Thanks,
	Stephane

2001-05-20  Stephane Carrez  <Stephane.Carrez@worldnet.fr>

	* gdb.c++/userdef.exp: This test fails for 68HC11 because C++
	iostream is not available.
Index: testsuite/gdb.c++/userdef.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.c++/userdef.exp,v
retrieving revision 1.3
diff -u -p -r1.3 userdef.exp
--- userdef.exp	2001/03/21 20:51:16	1.3
+++ userdef.exp	2001/05/20 11:40:02
@@ -1,5 +1,5 @@
 # Tests of overloaded operators resolution.
-# Copyright 1998, 1999 Free Software Foundation, Inc.
+# Copyright 1998, 1999, 2001 Free Software Foundation, Inc.
 
 # This program is free software; you can redistribute it and/or modify
 # it under the terms of the GNU General Public License as published by
@@ -28,6 +28,9 @@ if $tracelevel then {
 }
 
 if { [skip_cplus_tests] } { continue }
+
+# The C++ iostream is not available on embedded 68HC11.
+if [istarget "m6811-*-*"] { continue }
 
 set testfile "userdef"
 set srcfile ${testfile}.cc
From Stephane.Carrez@worldnet.fr Sun May 20 04:53:00 2001
From: Stephane Carrez <Stephane.Carrez@worldnet.fr>
To: gdb-patches@sources.redhat.com
Subject: [PATCH]: Fix return command for HC11 (pop_frame, prologue analysis)
Date: Sun, 20 May 2001 04:53:00 -0000
Message-id: <3B07B15D.802A7749@worldnet.fr>
X-SW-Source: 2001-05/msg00369.html
Content-length: 2077

Hi!

I've committed the following patch that fixes the 'return' command for HC11/HC12.
 - When poping the frame, the stack pointer was not set correctly,
 - During 68HC12 prologue analysis, the pc was not updated for some instructions
 - The save address of registers saved during the prologue was not correct
   (need to take into account the stack correction for HC11)

Stephane

2001-05-20  Stephane Carrez  <Stephane.Carrez@worldnet.fr>

	* m68hc11-tdep.c (m68hc11_pop_frame): Fix stack pointer computation.
	(m68hc11_analyze_instruction): Update the pc correctly.
	(m68hc11_guess_from_prologue): Take into account the stack correction
	for the saving address.
Index: m68hc11-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/m68hc11-tdep.c,v
retrieving revision 1.12
diff -u -p -r1.12 m68hc11-tdep.c
--- m68hc11-tdep.c	2001/03/01 01:39:21	1.12
+++ m68hc11-tdep.c	2001/05/20 11:38:49
@@ -334,7 +334,7 @@ m68hc11_pop_frame (void)
                           read_memory_integer (frame->saved_regs[regnum], 2));
 
       write_register (HARD_PC_REGNUM, frame->extra_info->return_pc);
-      sp = fp + frame->extra_info->size;
+      sp = (fp + frame->extra_info->size + 2) & 0x0ffff;
       write_register (HARD_SP_REGNUM, sp);
     }
   flush_cached_frames ();
@@ -489,10 +489,12 @@ m68hc11_analyze_instruction (struct insn
                   v = read_memory_unsigned_integer (*pc + j + 1, 1);
                   if (buffer[j] & 1)
                     v |= 0xff00;
+                  *pc = *pc + 1;
                 }
               else if (buffer[j] == 0xf2)
                 {
                   v = read_memory_unsigned_integer (*pc + j + 1, 2);
+                  *pc = *pc + 2;
                 }
               cur_val = v;
               break;
@@ -587,7 +589,7 @@ m68hc11_guess_from_prologue (CORE_ADDR p
   func_end = pc + 128;
   found_frame_point = 0;
   *frame_offset = 0;
-  save_addr = fp;
+  save_addr = fp + STACK_CORRECTION;
   while (!done && pc + 2 < func_end)
     {
       struct insn_sequence *seq;
From chastain@cygnus.com Sun May 20 05:02:00 2001
From: Michael Elizabeth Chastain <chastain@cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Subject: Patches coming for 8 test scripts with duplicate test names
Date: Sun, 20 May 2001 05:02:00 -0000
Message-id: <200105201207.FAA10047@bosch.cygnus.com>
X-SW-Source: 2001-05/msg00370.html
Content-length: 508

I'm submitting 8 patches to fix 8 test scripts which have duplicate
test names.  (I know of 34 such test scripts).

  gdb.base/callfuncs.exp
  gdb.base/commands.exp
  gdb.base/condbreak.exp
  gdb.base/dbx.exp
  gdb.base/default.exp
  gdb.base/define.exp
  gdb.base/ending-run.exp
  gdb.base/long_long.exp

These 8 are trivial.  If this goes well, I'll submit some non-trivial
patches as well.  Some scripts are written with gdb_expect, and they get
a lot shorter when I rewrite them with gdb_test.

Michael


^ permalink raw reply	[flat|nested] 4+ messages in thread
end of thread, other threads:[~2001-05-23  9:18 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-05-20  4:44 [RFA]: DejaGNU support for 68HC11/68HC12 Stephane Carrez
2001-05-21  8:44 ` [DejaGnu] " Rob Savoye
2001-05-21 14:18   ` Stephane Carrez
2001-05-23  9:18   ` Fernando Nasser

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