[RFA] New GDB target iq2000

[RFA] New GDB target iq2000

[Corinna Vinschen]

Hi,

this posting contributes the iq2000 code for GDB.

There's just one problem with it.  Older GCC code (older than two days,
actually), emits an asymmetrical register numbering in the dwarf2 debugging
output.  The iq2000 uses register 31 as link register, which contains the
return address to the calling function.  For some reason GCC emitted the
register number 26 in the dwarf2 information for this register.  Every
other register has been used unchanged in dwarf2, so there was no
unambiguous translation from dwarf2 register numbers to real register
numbers, if the dwarf2 register was "26".  This has been fixed yesterday
in GCC HEAD.

As a result, the dwarf2 frame sniffer has a problem with code generated
by GCC's older than two days.  This is no problem for the iq2000 frame
sniffer implemented in iq2000-tdep.c, but as usual, the iq2000 frame
sniffer is appended after the dwarf2 frame sniffer:

    frame_unwind_append_sniffer (gdbarch, dwarf2_frame_sniffer);
    frame_unwind_append_sniffer (gdbarch, iq2000_frame_sniffer);

Would that be a good reason to disable the dwarf2 frame sniffer for now?
Or shall I leave that as is?


Corinna

ChangeLog:
==========

2005-02-??  Corinna Vinschen  <vinschen@redhat.com>

	* Makefile.in: Add dependencies for iq2000-tdep.o.
	* configure.tgt: Add iq2000-*-* target.
	* iq2000-tdep.c: New file.
	* config/iq2000/iq2000.mt: New file.

testsuite/ChangeLog:
====================

2005-02-??  Corinna Vinschen  <vinschen@redhat.com>

	* gdb.asm/asm-source.exp: Add iq2000 case.
	* gdb.asm/iq2000.inc: New file.

Index: Makefile.in
===================================================================
RCS file: /cvs/src/src/gdb/Makefile.in,v
retrieving revision 1.699
diff -u -p -r1.699 Makefile.in
--- Makefile.in	16 Feb 2005 13:21:47 -0000	1.699
+++ Makefile.in	21 Feb 2005 20:17:32 -0000
@@ -2115,6 +2115,10 @@ inf-ttrace.o: inf-ttrace.c $(defs_h) $(c
 interps.o: interps.c $(defs_h) $(gdbcmd_h) $(ui_out_h) $(event_loop_h) \
 	$(event_top_h) $(interps_h) $(completer_h) $(gdb_string_h) \
 	$(gdb_events_h) $(gdb_assert_h) $(top_h) $(exceptions_h)
+iq2000-tdep.o: iq2000-tdep.c $(defs_h) $(frame_h) $(frame_base_h) \
+	$(frame_unwind_h) $(dwarf2_frame_h) $(gdbtypes_h) $(value_h) \
+	$(dis_asm_h) $(gdb_string_h) $(arch_utils_h) $(regcache_h) \
+	$(osabi_h) $(gdbcore_h)
 irix5-nat.o: irix5-nat.c $(defs_h) $(inferior_h) $(gdbcore_h) $(target_h) \
 	$(regcache_h) $(gdb_string_h) $(gregset_h) $(mips_tdep_h)
 jv-exp.o: jv-exp.c $(defs_h) $(gdb_string_h) $(expression_h) $(value_h) \
Index: configure.tgt
===================================================================
RCS file: /cvs/src/src/gdb/configure.tgt,v
retrieving revision 1.159
diff -u -p -r1.159 configure.tgt
--- configure.tgt	12 Feb 2005 10:38:50 -0000	1.159
+++ configure.tgt	21 Feb 2005 20:17:33 -0000
@@ -102,6 +102,8 @@ ia64-*-linux*)		gdb_target=linux
 			;;
 ia64*-*-*)		gdb_target=ia64 ;;
 
+iq2000-*-*)		gdb_target=iq2000 ;;
+
 m32r*-*-linux*)		gdb_target=linux ;;
 m32r*-*-*)		gdb_target=m32r ;;
 
Index: iq2000-tdep.c
===================================================================
RCS file: iq2000-tdep.c
diff -N iq2000-tdep.c
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ iq2000-tdep.c	21 Feb 2005 20:17:33 -0000
@@ -0,0 +1,874 @@
+/* Target-dependent code for the IQ2000 architecture, for GDB, the GNU
+   Debugger.
+
+   Copyright 2000, 2004, 2005 Free Software Foundation, Inc.
+
+   Contributed by Red Hat.
+
+   This file is part of GDB.
+
+   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.  */
+
+#include "defs.h"
+#include "frame.h"
+#include "frame-base.h"
+#include "frame-unwind.h"
+#include "dwarf2-frame.h"
+#include "gdbtypes.h"
+#include "value.h"
+#include "dis-asm.h"
+#include "gdb_string.h"
+#include "arch-utils.h"
+#include "regcache.h"
+#include "osabi.h"
+#include "gdbcore.h"
+
+enum gdb_regnum
+{
+  E_R0_REGNUM,  E_R1_REGNUM,  E_R2_REGNUM,  E_R3_REGNUM, 
+  E_R4_REGNUM,  E_R5_REGNUM,  E_R6_REGNUM,  E_R7_REGNUM, 
+  E_R8_REGNUM,  E_R9_REGNUM,  E_R10_REGNUM, E_R11_REGNUM, 
+  E_R12_REGNUM, E_R13_REGNUM, E_R14_REGNUM, E_R15_REGNUM, 
+  E_R16_REGNUM, E_R17_REGNUM, E_R18_REGNUM, E_R19_REGNUM, 
+  E_R20_REGNUM, E_R21_REGNUM, E_R22_REGNUM, E_R23_REGNUM, 
+  E_R24_REGNUM, E_R25_REGNUM, E_R26_REGNUM, E_R27_REGNUM, 
+  E_R28_REGNUM, E_R29_REGNUM, E_R30_REGNUM, E_R31_REGNUM, 
+  E_PC_REGNUM, 
+  E_LR_REGNUM        = E_R31_REGNUM, /* Link register.  */
+  E_SP_REGNUM        = E_R29_REGNUM, /* Stack pointer.  */
+  E_FP_REGNUM        = E_R27_REGNUM, /* Frame pointer.  */
+  E_FN_RETURN_REGNUM = E_R2_REGNUM,  /* Function return value register.  */
+  E_1ST_ARGREG       = E_R4_REGNUM,  /* 1st  function arg register.  */
+  E_LAST_ARGREG      = E_R11_REGNUM, /* Last function arg register.  */
+  E_NUM_REGS         = E_PC_REGNUM + 1
+};
+
+/* Use an invalid address value as 'not available' marker.  */
+enum { REG_UNAVAIL = (CORE_ADDR) -1 };
+
+struct iq2000_frame_cache
+{
+  /* Base address.  */
+  CORE_ADDR  base;
+  CORE_ADDR  pc;
+  LONGEST    framesize;
+  int        using_fp;
+  CORE_ADDR  saved_sp;
+  CORE_ADDR  saved_regs [E_NUM_REGS];
+};
+
+/* Harvard methods: */
+
+static CORE_ADDR
+insn_ptr_from_addr (CORE_ADDR addr)	/* CORE_ADDR to target pointer.  */
+{
+  return addr & 0x7fffffffL;
+}
+
+static CORE_ADDR
+insn_addr_from_ptr (CORE_ADDR ptr)	/* target_pointer to CORE_ADDR.  */
+{
+  return (ptr & 0x7fffffffL) | 0x80000000L;
+}
+
+/* Function: pointer_to_address
+   Convert a target pointer to an address in host (CORE_ADDR) format. */
+
+static CORE_ADDR
+iq2000_pointer_to_address (struct type * type, const void * buf)
+{
+  enum type_code target = TYPE_CODE (TYPE_TARGET_TYPE (type));
+  CORE_ADDR addr = extract_unsigned_integer (buf, TYPE_LENGTH (type));
+
+  if (target == TYPE_CODE_FUNC
+      || target == TYPE_CODE_METHOD
+      || (TYPE_FLAGS (TYPE_TARGET_TYPE (type)) & TYPE_FLAG_CODE_SPACE) != 0)
+    addr = insn_addr_from_ptr (addr);
+
+  return addr;
+}
+
+/* Function: address_to_pointer
+   Convert a host-format address (CORE_ADDR) into a target pointer.  */
+
+static void
+iq2000_address_to_pointer (struct type *type, void *buf, CORE_ADDR addr)
+{
+  enum type_code target = TYPE_CODE (TYPE_TARGET_TYPE (type));
+
+  if (target == TYPE_CODE_FUNC || target == TYPE_CODE_METHOD)
+    addr = insn_ptr_from_addr (addr);
+  store_unsigned_integer (buf, TYPE_LENGTH (type), addr);
+}
+
+/* Real register methods: */
+
+/* Function: register_name
+   Returns the name of the iq2000 register number N.  */
+
+static const char *
+iq2000_register_name (int regnum)
+{
+  static const char * names[E_NUM_REGS] =
+    {
+      "r0",  "r1",  "r2",  "r3",  "r4",
+      "r5",  "r6",  "r7",  "r8",  "r9",
+      "r10", "r11", "r12", "r13", "r14",
+      "r15", "r16", "r17", "r18", "r19",
+      "r20", "r21", "r22", "r23", "r24",
+      "r25", "r26", "r27", "r28", "r29",
+      "r30", "r31",
+      "pc"
+    };
+  if (regnum < 0 || regnum >= E_NUM_REGS)
+    return NULL;
+  return names[regnum];
+}
+
+/* Prologue analysis methods:  */
+
+/* ADDIU insn (001001 rs(5) rt(5) imm(16)).  */
+#define INSN_IS_ADDIU(X)	(((X) & 0xfc000000) == 0x24000000) 
+#define ADDIU_REG_SRC(X)	(((X) & 0x03e00000) >> 21)
+#define ADDIU_REG_TGT(X)	(((X) & 0x001f0000) >> 16)
+#define ADDIU_IMMEDIATE(X)	((signed short) ((X) & 0x0000ffff))
+
+/* "MOVE" (OR) insn (000000 rs(5) rt(5) rd(5) 00000 100101).  */
+#define INSN_IS_MOVE(X)		(((X) & 0xffe007ff) == 0x00000025)
+#define MOVE_REG_SRC(X)		(((X) & 0x001f0000) >> 16)
+#define MOVE_REG_TGT(X)		(((X) & 0x0000f800) >> 11)
+
+/* STORE WORD insn (101011 rs(5) rt(5) offset(16)).  */
+#define INSN_IS_STORE_WORD(X)	(((X) & 0xfc000000) == 0xac000000)
+#define SW_REG_INDEX(X)		(((X) & 0x03e00000) >> 21)
+#define SW_REG_SRC(X)		(((X) & 0x001f0000) >> 16)
+#define SW_OFFSET(X)		((signed short) ((X) & 0x0000ffff))
+
+/* Function: find_last_line_symbol
+
+   Given an address range, first find a line symbol corresponding to
+   the starting address.  Then find the last line symbol within the 
+   range that has a line number less than or equal to the first line.
+
+   For optimized code with code motion, this finds the last address
+   for the lowest-numbered line within the address range.  */
+
+static struct symtab_and_line
+find_last_line_symbol (CORE_ADDR start, CORE_ADDR end, int notcurrent)
+{
+  struct symtab_and_line sal = find_pc_line (start, notcurrent);
+  struct symtab_and_line best_sal = sal;
+
+  if (sal.pc == 0 || sal.line == 0 || sal.end == 0)
+    return sal;
+
+  do
+    {
+      if (sal.line && sal.line <= best_sal.line)
+	best_sal = sal;
+      sal = find_pc_line (sal.end, notcurrent);
+    }
+  while (sal.pc && sal.pc < end);
+
+  return best_sal;
+}
+
+/* Function: scan_prologue
+   Decode the instructions within the given address range.
+   Decide when we must have reached the end of the function prologue.
+   If a frame_info pointer is provided, fill in its prologue information.
+
+   Returns the address of the first instruction after the prologue.  */
+
+static CORE_ADDR
+iq2000_scan_prologue (CORE_ADDR scan_start,
+		      CORE_ADDR scan_end,
+		      struct frame_info *fi,
+		      struct iq2000_frame_cache *cache)
+{
+  struct symtab_and_line sal;
+  CORE_ADDR pc;
+  CORE_ADDR loop_end;
+  int found_store_lr = 0;
+  int found_decr_sp = 0;
+  int srcreg;
+  int tgtreg;
+  signed short offset;
+
+  if (scan_end == (CORE_ADDR) 0)
+    {
+      loop_end = scan_start + 100;
+      sal.end = sal.pc = 0;
+    }
+  else
+    {
+      loop_end = scan_end;
+      if (fi)
+	sal = find_last_line_symbol (scan_start, scan_end, 0);
+    }
+
+  /* Saved registers:
+     We first have to save the saved register's offset, and 
+     only later do we compute its actual address.  Since the
+     offset can be zero, we must first initialize all the 
+     saved regs to minus one (so we can later distinguish 
+     between one that's not saved, and one that's saved at zero). */
+  for (srcreg = 0; srcreg < E_NUM_REGS; srcreg ++)
+    cache->saved_regs[srcreg] = -1;
+  cache->using_fp = 0;
+  cache->framesize = 0;
+
+  for (pc = scan_start; pc < loop_end; pc += 4)
+    {
+      LONGEST insn = read_memory_unsigned_integer (pc, 4);
+      /* Skip any instructions writing to (sp) or decrementing the
+         SP. */
+      if ((insn & 0xffe00000) == 0xac200000)
+	{
+	  /* sw using SP/%1 as base.  */
+	  /* LEGACY -- from assembly-only port.  */
+	  tgtreg = ((insn >> 16) & 0x1f);
+	  if (tgtreg >= 0 && tgtreg < E_NUM_REGS)
+	    cache->saved_regs[tgtreg] = -((signed short) (insn & 0xffff));
+
+	  if (tgtreg == E_LR_REGNUM)
+	    found_store_lr = 1;
+	  continue;
+	}
+
+      if ((insn & 0xffff8000) == 0x20218000)
+	{
+	  /* addi %1, %1, -N == addi %sp, %sp, -N */
+	  /* LEGACY -- from assembly-only port */
+	  found_decr_sp = 1;
+	  cache->framesize = -((signed short) (insn & 0xffff));
+	  continue;
+	}
+
+      if (INSN_IS_ADDIU (insn))
+	{
+	  srcreg = ADDIU_REG_SRC (insn);
+	  tgtreg = ADDIU_REG_TGT (insn);
+	  offset = ADDIU_IMMEDIATE (insn);
+	  if (srcreg == E_SP_REGNUM && tgtreg == E_SP_REGNUM)
+	    cache->framesize = -offset;
+	  continue;
+	}
+
+      if (INSN_IS_STORE_WORD (insn))
+	{
+	  srcreg = SW_REG_SRC (insn);
+	  tgtreg = SW_REG_INDEX (insn);
+	  offset = SW_OFFSET (insn);
+
+	  if (tgtreg == E_SP_REGNUM || tgtreg == E_FP_REGNUM)
+	    {
+	      /* "push" to stack (via SP or FP reg) */
+	      if (cache->saved_regs[srcreg] == -1) /* Don't save twice.  */
+		cache->saved_regs[srcreg] = offset;
+	      continue;
+	    }
+	}
+
+      if (INSN_IS_MOVE (insn))
+	{
+	  srcreg = MOVE_REG_SRC (insn);
+	  tgtreg = MOVE_REG_TGT (insn);
+
+	  if (srcreg == E_SP_REGNUM && tgtreg == E_FP_REGNUM)
+	    {
+	      /* Copy sp to fp.  */
+	      cache->using_fp = 1;
+	      continue;
+	    }
+	}
+
+      /* Unknown instruction encountered in frame.  Bail out?
+         1) If we have a subsequent line symbol, we can keep going.
+         2) If not, we need to bail out and quit scanning instructions.  */
+
+      if (fi && sal.end && (pc < sal.end)) /* Keep scanning.  */
+	continue;
+      else /* bail */
+	break;
+    }
+
+  return pc;
+}
+
+static void
+iq2000_init_frame_cache (struct iq2000_frame_cache *cache)
+{
+  int i;
+
+  cache->base = 0;
+  cache->framesize = 0;
+  cache->using_fp = 0;
+  cache->saved_sp = 0;
+  for (i = 0; i < E_NUM_REGS; i++)
+    cache->saved_regs[i] = -1;
+}
+
+/* Function: iq2000_skip_prologue
+   If the input address is in a function prologue, 
+   returns the address of the end of the prologue;
+   else returns the input address.
+
+   Note: the input address is likely to be the function start, 
+   since this function is mainly used for advancing a breakpoint
+   to the first line, or stepping to the first line when we have
+   stepped into a function call.  */
+
+static CORE_ADDR
+iq2000_skip_prologue (CORE_ADDR pc)
+{
+  CORE_ADDR func_addr = 0 , func_end = 0;
+
+  if (find_pc_partial_function (pc, NULL, & func_addr, & func_end))
+    {
+      struct symtab_and_line sal;
+      struct iq2000_frame_cache cache;
+
+      /* Found a function.  */
+      sal = find_pc_line (func_addr, 0);
+      if (sal.end && sal.end < func_end)
+	/* Found a line number, use it as end of prologue.  */
+	return sal.end;
+
+      /* No useable line symbol.  Use prologue parsing method.  */
+      iq2000_init_frame_cache (&cache);
+      return iq2000_scan_prologue (func_addr, func_end, NULL, &cache);
+    }
+
+  /* No function symbol -- just return the PC.  */
+  return (CORE_ADDR) pc;
+}
+
+static struct iq2000_frame_cache *
+iq2000_frame_cache (struct frame_info *next_frame, void **this_cache)
+{
+  struct iq2000_frame_cache *cache;
+  CORE_ADDR current_pc;
+  int i;
+
+  if (*this_cache)
+    return *this_cache;
+
+  cache = FRAME_OBSTACK_ZALLOC (struct iq2000_frame_cache);
+  iq2000_init_frame_cache (cache);
+  *this_cache = cache;
+
+  cache->base = frame_unwind_register_unsigned (next_frame, E_FP_REGNUM);
+  //if (cache->base == 0)
+    //return cache;
+
+  current_pc = frame_pc_unwind (next_frame);
+  find_pc_partial_function (current_pc, NULL, &cache->pc, NULL);
+  if (cache->pc != 0)
+    iq2000_scan_prologue (cache->pc, current_pc, next_frame, cache);
+  if (!cache->using_fp)
+    cache->base = frame_unwind_register_unsigned (next_frame, E_SP_REGNUM);
+
+  cache->saved_sp = cache->base + cache->framesize;
+
+  for (i = 0; i < E_NUM_REGS; i++)
+    if (cache->saved_regs[i] != -1)
+      cache->saved_regs[i] += cache->base;
+
+  return cache;
+}
+
+static void
+iq2000_frame_prev_register (struct frame_info *next_frame, void **this_cache,
+			    int regnum, int *optimizedp,
+			    enum lval_type *lvalp, CORE_ADDR *addrp,
+			    int *realnump, void *valuep)
+{
+  struct iq2000_frame_cache *cache = iq2000_frame_cache (next_frame, this_cache);
+  if (regnum == E_SP_REGNUM && cache->saved_sp)
+    {
+      *optimizedp = 0;
+      *lvalp = not_lval;
+      *addrp = 0;
+      *realnump = -1;
+      if (valuep)
+        store_unsigned_integer (valuep, 4, cache->saved_sp);
+      return;
+    }
+
+  if (regnum == E_PC_REGNUM)
+    regnum = E_LR_REGNUM;
+
+  if (regnum < E_NUM_REGS && cache->saved_regs[regnum] != -1)
+    {
+      *optimizedp = 0;
+      *lvalp = lval_memory;
+      *addrp = cache->saved_regs[regnum];
+      *realnump = -1;
+      if (valuep)
+        read_memory (*addrp, valuep, register_size (current_gdbarch, regnum));
+      return;
+    }
+
+  *optimizedp = 0;
+  *lvalp = lval_register;
+  *addrp = 0; 
+  *realnump = regnum;
+  if (valuep)
+    frame_unwind_register (next_frame, (*realnump), valuep);
+}
+
+static void
+iq2000_frame_this_id (struct frame_info *next_frame, void **this_cache,
+		      struct frame_id *this_id)
+{
+  struct iq2000_frame_cache *cache = iq2000_frame_cache (next_frame, this_cache);
+
+  /* This marks the outermost frame.  */
+  if (cache->base == 0) 
+    return;
+
+  *this_id = frame_id_build (cache->saved_sp, cache->pc);
+}
+
+static const struct frame_unwind iq2000_frame_unwind = {
+  NORMAL_FRAME,
+  iq2000_frame_this_id,
+  iq2000_frame_prev_register
+};
+
+static const struct frame_unwind *
+iq2000_frame_sniffer (struct frame_info *next_frame)
+{
+  return &iq2000_frame_unwind;
+}
+
+static CORE_ADDR
+iq2000_unwind_sp (struct gdbarch *gdbarch, struct frame_info *next_frame)
+{
+  return frame_unwind_register_unsigned (next_frame, E_SP_REGNUM);
+}   
+
+static CORE_ADDR
+iq2000_unwind_pc (struct gdbarch *gdbarch, struct frame_info *next_frame)
+{
+  return frame_unwind_register_unsigned (next_frame, E_PC_REGNUM);
+}
+
+static struct frame_id
+iq2000_unwind_dummy_id (struct gdbarch *gdbarch, struct frame_info *next_frame)
+{
+  return frame_id_build (iq2000_unwind_sp (gdbarch, next_frame),
+                         frame_pc_unwind (next_frame));
+}
+
+static CORE_ADDR
+iq2000_frame_base_address (struct frame_info *next_frame, void **this_cache)
+{
+  struct iq2000_frame_cache *cache = iq2000_frame_cache (next_frame, this_cache);
+
+  return cache->base;
+}
+  
+static const struct frame_base iq2000_frame_base = {
+  &iq2000_frame_unwind,
+  iq2000_frame_base_address,
+  iq2000_frame_base_address, 
+  iq2000_frame_base_address
+};
+
+static const unsigned char *
+iq2000_breakpoint_from_pc (CORE_ADDR *pcptr, int *lenptr)
+{
+  static const unsigned char big_breakpoint[] = { 0x00, 0x00, 0x00, 0x0d };
+  static const unsigned char little_breakpoint[] = { 0x0d, 0x00, 0x00, 0x00 };
+
+  if ((*pcptr & 3) != 0)
+    error ("breakpoint_from_pc: invalid breakpoint address 0x%lx",
+	   (long) *pcptr);
+
+  *lenptr = 4;
+  return (TARGET_BYTE_ORDER == BFD_ENDIAN_BIG) ? big_breakpoint
+					       : little_breakpoint;
+}
+
+/* Target function return value methods: */
+
+/* Function: store_return_value
+   Copy the function return value from VALBUF into the 
+   proper location for a function return.  */
+
+static void
+iq2000_store_return_value (struct type *type, struct regcache *regcache,
+			   const void *valbuf)
+{
+  int len = TYPE_LENGTH (type);
+  int regno = E_FN_RETURN_REGNUM;
+
+  while (len > 0)
+    {
+      char buf[4];
+      int size = len % 4 ?: 4;
+
+      memset (buf, 0, 4);
+      memcpy (buf + 4 - size, valbuf, size);
+      regcache_raw_write (regcache, regno++, buf);
+      len -= size;
+      valbuf = ((char *) valbuf) + size;
+    }
+}
+
+/* Function: use_struct_convention 
+   Returns non-zero if the given struct type will be returned using
+   a special convention, rather than the normal function return method.  */
+
+static int
+iq2000_use_struct_convention (struct type *type)
+{
+  return ((TYPE_CODE (type) == TYPE_CODE_STRUCT)
+	  || (TYPE_CODE (type) == TYPE_CODE_UNION))
+	 && TYPE_LENGTH (type) > 8;
+}
+
+/* Function: extract_return_value
+   Copy the function's return value into VALBUF. 
+   This function is called only in the context of "target function calls",
+   ie. when the debugger forces a function to be called in the child, and
+   when the debugger forces a function to return prematurely via the
+   "return" command.  */
+
+static void
+iq2000_extract_return_value (struct type *type, struct regcache *regcache,
+			     void *valbuf)
+{
+  /* If the function's return value is 8 bytes or less, it is
+     returned in a register, and if larger than 8 bytes, it is 
+     returned in a stack location which is pointed to by the same
+     register.  */
+  CORE_ADDR return_buffer;
+  int len = TYPE_LENGTH (type);
+
+  if (len <= (2 * 4))
+    {
+      int regno = E_FN_RETURN_REGNUM;
+
+      /* Return values of <= 8 bytes are returned in 
+	 FN_RETURN_REGNUM.  */
+      while (len > 0)
+	{
+	  ULONGEST tmp;
+	  int size = len % 4 ?: 4;
+
+	  /* By using store_unsigned_integer we avoid having to
+	     do anything special for small big-endian values.  */
+	  regcache_cooked_read_unsigned (regcache, regno++, &tmp);
+	  store_unsigned_integer (valbuf, size, tmp);
+	  len -= size;
+	  valbuf = ((char *) valbuf) + size;
+	}
+    }
+  else
+    {
+      /* Return values > 8 bytes are returned in memory,
+	 pointed to by FN_RETURN_REGNUM.  */
+      regcache_cooked_read (regcache, E_FN_RETURN_REGNUM, & return_buffer);
+      read_memory (return_buffer, valbuf, TYPE_LENGTH (type));
+    }
+}
+
+static enum return_value_convention
+iq2000_return_value (struct gdbarch *gdbarch, struct type *type,
+		     struct regcache *regcache,
+		     void *readbuf, const void *writebuf)
+{
+  if (iq2000_use_struct_convention (type))
+    return RETURN_VALUE_STRUCT_CONVENTION;
+  if (writebuf)
+    iq2000_store_return_value (type, regcache, writebuf);
+  else if (readbuf)
+    iq2000_extract_return_value (type, regcache, readbuf);
+  return RETURN_VALUE_REGISTER_CONVENTION;
+}
+
+/* Function: register_virtual_type
+   Returns the default type for register N.  */
+
+static struct type *
+iq2000_register_type (struct gdbarch *gdbarch, int regnum)
+{
+  return builtin_type_int32;
+}
+
+static CORE_ADDR
+iq2000_frame_align (struct gdbarch *ignore, CORE_ADDR sp)
+{
+  /* This is the same frame alignment used by gcc.  */
+  return ((sp + 7) & ~7);
+}
+
+/* Convenience function to check 8-byte types for being a scalar type
+   or a struct with only one long long or double member. */
+static int
+iq2000_pass_8bytetype_by_address (struct type *type)
+{
+  struct type *ftype;
+
+  /* Skip typedefs.  */
+  while (TYPE_CODE (type) == TYPE_CODE_TYPEDEF)
+    type = TYPE_TARGET_TYPE (type);
+  /* Non-struct and non-union types are always passed by value.  */
+  if (TYPE_CODE (type) != TYPE_CODE_STRUCT
+      && TYPE_CODE (type) != TYPE_CODE_UNION)
+    return 0;
+  /* Structs with more than 1 field are always passed by address.  */
+  if (TYPE_NFIELDS (type) != 1)
+    return 1;
+  /* Get field type.  */
+  ftype = (TYPE_FIELDS (type))[0].type;
+  /* The field type must have size 8, otherwise pass by address.  */
+  if (TYPE_LENGTH (ftype) != 8)
+    return 1;
+  /* Skip typedefs of field type.  */
+  while (TYPE_CODE (ftype) == TYPE_CODE_TYPEDEF)
+    ftype = TYPE_TARGET_TYPE (ftype);
+  /* If field is int or float, pass by value.  */
+  if (TYPE_CODE (ftype) == TYPE_CODE_FLT
+      || TYPE_CODE (ftype) == TYPE_CODE_INT)
+    return 0;
+  /* Everything else, pass by address. */
+  return 1;
+}
+
+static CORE_ADDR
+iq2000_push_dummy_call (struct gdbarch *gdbarch, struct value *function,
+		        struct regcache *regcache, CORE_ADDR bp_addr,
+		        int nargs, struct value **args, CORE_ADDR sp,
+		        int struct_return, CORE_ADDR struct_addr)
+{
+  const bfd_byte *val;
+  bfd_byte buf[4];
+  struct type *type;
+  int i, argreg, typelen, slacklen;
+  int stackspace = 0;
+  /* Used to copy struct arguments into the stack. */
+  CORE_ADDR struct_ptr;
+
+  /* First determine how much stack space we will need. */
+  for (i = 0, argreg = E_1ST_ARGREG + (struct_return != 0); i < nargs; i++)
+    {
+      type = value_type (args[i]);
+      typelen = TYPE_LENGTH (type);
+      if (typelen <= 4)
+        {
+          /* Scalars of up to 4 bytes, 
+             structs of up to 4 bytes, and
+             pointers.  */
+          if (argreg <= E_LAST_ARGREG)
+            argreg++;
+          else
+            stackspace += 4;
+        }
+      else if (typelen == 8 && !iq2000_pass_8bytetype_by_address (type))
+        {
+          /* long long, 
+             double, and possibly
+             structs with a single field of long long or double. */
+          if (argreg <= E_LAST_ARGREG - 1)
+            {
+              /* 8-byte arg goes into a register pair
+                 (must start with an even-numbered reg) */
+              if (((argreg - E_1ST_ARGREG) % 2) != 0)
+                argreg ++;
+              argreg += 2;
+            }
+          else
+            {
+              argreg = E_LAST_ARGREG + 1;       /* no more argregs. */
+              /* 8-byte arg goes on stack, must be 8-byte aligned. */
+              stackspace = ((stackspace + 7) & ~7);
+              stackspace += 8;
+            }
+        }
+      else
+	{
+	  /* Structs are passed as pointer to a copy of the struct.
+	     So we need room on the stack for a copy of the struct
+	     plus for the argument pointer. */
+          if (argreg <= E_LAST_ARGREG)
+            argreg++;
+          else
+            stackspace += 4;
+	  /* Care for 8-byte alignment of structs saved on stack.  */
+	  stackspace += ((typelen + 7) & ~7);
+	}
+    }
+
+  /* Now copy params, in ascending order, into their assigned location
+     (either in a register or on the stack). */
+
+  sp -= (sp % 8);       /* align */
+  struct_ptr = sp;
+  sp -= stackspace;
+  sp -= (sp % 8);       /* align again */
+  stackspace = 0;
+
+  argreg = E_1ST_ARGREG;
+  if (struct_return)
+    {
+      /* A function that returns a struct will consume one argreg to do so. 
+       */
+      regcache_cooked_write_unsigned (regcache, argreg++, struct_addr);
+    }
+
+  for (i = 0; i < nargs; i++)
+    {
+      type = value_type (args[i]);
+      typelen = TYPE_LENGTH (type);
+      val = value_contents (args[i]);
+      if (typelen <= 4)
+        {
+          /* Char, short, int, float, pointer, and structs <= four bytes. */
+	  slacklen = (4 - (typelen % 4)) % 4;
+	  memset (buf, 0, sizeof (buf));
+	  memcpy (buf + slacklen, val, typelen);
+          if (argreg <= E_LAST_ARGREG)
+            {
+              /* Passed in a register. */
+	      regcache_raw_write (regcache, argreg++, buf);
+            }
+          else
+            {
+              /* Passed on the stack. */
+              write_memory (sp + stackspace, buf, 4);
+              stackspace += 4;
+            }
+        }
+      else if (typelen == 8 && !iq2000_pass_8bytetype_by_address (type))
+        {
+          /* (long long), (double), or struct consisting of 
+             a single (long long) or (double). */
+          if (argreg <= E_LAST_ARGREG - 1)
+            {
+              /* 8-byte arg goes into a register pair
+                 (must start with an even-numbered reg) */
+              if (((argreg - E_1ST_ARGREG) % 2) != 0)
+                argreg++;
+	      regcache_raw_write (regcache, argreg++, val);
+	      regcache_raw_write (regcache, argreg++, val + 4);
+            }
+          else
+            {
+              /* 8-byte arg goes on stack, must be 8-byte aligned. */
+              argreg = E_LAST_ARGREG + 1;       /* no more argregs. */
+              stackspace = ((stackspace + 7) & ~7);
+              write_memory (sp + stackspace, val, typelen);
+              stackspace += 8;
+            }
+        }
+      else
+        {
+	  /* Store struct beginning at the upper end of the previously
+	     computed stack space.  Then store the address of the struct
+	     using the usual rules for a 4 byte value.  */
+	  struct_ptr -= ((typelen + 7) & ~7);
+	  write_memory (struct_ptr, val, typelen);
+	  if (argreg <= E_LAST_ARGREG)
+	    regcache_cooked_write_unsigned (regcache, argreg++, struct_ptr);
+	  else
+	    {
+	      store_unsigned_integer (buf, 4, struct_ptr);
+	      write_memory (sp + stackspace, buf, 4);
+	      stackspace += 4;
+	    }
+        }
+    }
+
+  /* Store return address. */
+  regcache_cooked_write_unsigned (regcache, E_LR_REGNUM, bp_addr);
+
+  /* Update stack pointer.  */
+  regcache_cooked_write_unsigned (regcache, E_SP_REGNUM, sp);
+
+  /* And that should do it.  Return the new stack pointer. */
+  return sp;
+}
+
+/* Function: gdbarch_init
+   Initializer function for the iq2000 gdbarch vector.
+   Called by gdbarch.  Sets up the gdbarch vector(s) for this target.  */
+
+static struct gdbarch *
+iq2000_gdbarch_init (struct gdbarch_info info, struct gdbarch_list *arches)
+{
+  struct gdbarch *gdbarch;
+
+  /* Look up list for candidates - only one.  */
+  arches = gdbarch_list_lookup_by_info (arches, &info);
+  if (arches != NULL)
+    return arches->gdbarch;
+
+  gdbarch = gdbarch_alloc (&info, NULL);
+
+  set_gdbarch_num_regs             (gdbarch, E_NUM_REGS);
+  set_gdbarch_num_pseudo_regs      (gdbarch, 0);
+  set_gdbarch_sp_regnum            (gdbarch, E_SP_REGNUM);
+  set_gdbarch_pc_regnum            (gdbarch, E_PC_REGNUM);
+  set_gdbarch_register_name        (gdbarch, iq2000_register_name);
+  set_gdbarch_address_to_pointer   (gdbarch, iq2000_address_to_pointer);
+  set_gdbarch_pointer_to_address   (gdbarch, iq2000_pointer_to_address);
+  set_gdbarch_ptr_bit              (gdbarch, 4 * TARGET_CHAR_BIT);
+  set_gdbarch_short_bit            (gdbarch, 2 * TARGET_CHAR_BIT);
+  set_gdbarch_int_bit              (gdbarch, 4 * TARGET_CHAR_BIT);
+  set_gdbarch_long_bit             (gdbarch, 4 * TARGET_CHAR_BIT);
+  set_gdbarch_long_long_bit        (gdbarch, 8 * TARGET_CHAR_BIT);
+  set_gdbarch_float_bit            (gdbarch, 4 * TARGET_CHAR_BIT);
+  set_gdbarch_double_bit           (gdbarch, 8 * TARGET_CHAR_BIT);
+  set_gdbarch_long_double_bit      (gdbarch, 8 * TARGET_CHAR_BIT);
+  set_gdbarch_float_format         (gdbarch, & floatformat_ieee_single_big);
+  set_gdbarch_double_format        (gdbarch, & floatformat_ieee_double_big);
+  set_gdbarch_long_double_format   (gdbarch, & floatformat_ieee_double_big);
+  set_gdbarch_return_value	   (gdbarch, iq2000_return_value);
+  set_gdbarch_breakpoint_from_pc   (gdbarch, iq2000_breakpoint_from_pc);
+  set_gdbarch_frame_args_skip      (gdbarch, 0);
+  set_gdbarch_skip_prologue        (gdbarch, iq2000_skip_prologue);
+  set_gdbarch_decr_pc_after_break  (gdbarch, 0);
+  set_gdbarch_inner_than           (gdbarch, core_addr_lessthan);
+  set_gdbarch_print_insn           (gdbarch, print_insn_iq2000);
+  set_gdbarch_register_type (gdbarch, iq2000_register_type);
+  set_gdbarch_frame_align (gdbarch, iq2000_frame_align);
+  set_gdbarch_unwind_sp (gdbarch, iq2000_unwind_sp);
+  set_gdbarch_unwind_pc (gdbarch, iq2000_unwind_pc);
+  set_gdbarch_unwind_dummy_id (gdbarch, iq2000_unwind_dummy_id);
+  frame_base_set_default (gdbarch, &iq2000_frame_base);
+  set_gdbarch_push_dummy_call (gdbarch, iq2000_push_dummy_call);
+
+  gdbarch_init_osabi (info, gdbarch);
+
+  frame_unwind_append_sniffer (gdbarch, dwarf2_frame_sniffer);
+  frame_unwind_append_sniffer (gdbarch, iq2000_frame_sniffer);
+
+  return gdbarch;
+}
+
+/* Function: _initialize_iq2000_tdep
+   Initializer function for the iq2000 module.
+   Called by gdb at start-up. */
+
+void
+_initialize_iq2000_tdep (void)
+{
+  register_gdbarch_init (bfd_arch_iq2000, iq2000_gdbarch_init);
+}
Index: config/iq2000/iq2000.mt
===================================================================
RCS file: config/iq2000/iq2000.mt
diff -N config/iq2000/iq2000.mt
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ config/iq2000/iq2000.mt	21 Feb 2005 20:17:33 -0000
@@ -0,0 +1,3 @@
+TDEPFILES= iq2000-tdep.o
+SIM_OBS= remote-sim.o
+SIM= ../sim/iq2000/libsim.a
Index: testsuite/gdb.asm/asm-source.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.asm/asm-source.exp,v
retrieving revision 1.54
diff -u -p -r1.54 asm-source.exp
--- testsuite/gdb.asm/asm-source.exp	30 Oct 2004 21:49:30 -0000	1.54
+++ testsuite/gdb.asm/asm-source.exp	21 Feb 2005 20:17:33 -0000
@@ -122,6 +122,9 @@ switch -glob -- [istarget] {
         set asm-flags "-I${srcdir}/${subdir} -I${objdir}/${subdir}"
 	set debug-flags "-gdwarf-2"
     }
+    "iq2000-*-*" {
+    	set asm-arch iq2000
+    }
     "hppa*-linux-*" {
         set asm-arch pa
         set asm-flags "-I${srcdir}/${subdir} -I${objdir}/${subdir}"
Index: testsuite/gdb.asm/iq2000.inc
===================================================================
RCS file: testsuite/gdb.asm/iq2000.inc
diff -N testsuite/gdb.asm/iq2000.inc
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ testsuite/gdb.asm/iq2000.inc	21 Feb 2005 20:17:33 -0000
@@ -0,0 +1,41 @@
+	comment "subroutine prologue"
+	.macro gdbasm_enter
+	addiu %29, %29, 0xfffc
+	sw %31,0(%29)
+	.endm
+
+	comment "subroutine epilogue"
+	.macro gdbasm_leave
+	lw %31,0(%29)
+	addiu %29, %29, 4
+	jr %31
+	nop
+	.endm
+
+	.macro gdbasm_call subr
+	jal \subr
+	nop
+	.endm
+
+	.macro gdbasm_several_nops
+	nop
+	nop
+	nop
+	nop
+	.endm
+
+	comment "exit (0)"
+	.macro gdbasm_exit0
+	ori  %4, %0, 1	# SYS_exit
+	ori  %5, %0, 0	# normal exit code
+	ori  %6, %0, 0
+	ori  %7, %0, 0
+	syscall
+	.endm
+
+	comment "crt0 startup"
+	.macro gdbasm_startup
+	andi %0, %0, 0
+	addiu %29, %0, 0xffc
+	.endm
+

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat, Inc.

Re: [RFA] New GDB target iq2000

[Jim Blandy]

Hi, Corinna.

> +/* Function: gdbarch_init
> +   Initializer function for the iq2000 gdbarch vector.
> +   Called by gdbarch.  Sets up the gdbarch vector(s) for this target.  */
> +
> +static struct gdbarch *
> +iq2000_gdbarch_init (struct gdbarch_info info, struct gdbarch_list *arches)
> +{
> +  struct gdbarch *gdbarch;
> +
> +  /* Look up list for candidates - only one.  */
> +  arches = gdbarch_list_lookup_by_info (arches, &info);
> +  if (arches != NULL)
> +    return arches->gdbarch;
> +
> +  gdbarch = gdbarch_alloc (&info, NULL);
> +
> +  set_gdbarch_num_regs             (gdbarch, E_NUM_REGS);
> +  set_gdbarch_num_pseudo_regs      (gdbarch, 0);
> +  set_gdbarch_sp_regnum            (gdbarch, E_SP_REGNUM);
> +  set_gdbarch_pc_regnum            (gdbarch, E_PC_REGNUM);
> +  set_gdbarch_register_name        (gdbarch, iq2000_register_name);
> +  set_gdbarch_address_to_pointer   (gdbarch, iq2000_address_to_pointer);
> +  set_gdbarch_pointer_to_address   (gdbarch, iq2000_pointer_to_address);
> +  set_gdbarch_ptr_bit              (gdbarch, 4 * TARGET_CHAR_BIT);
> +  set_gdbarch_short_bit            (gdbarch, 2 * TARGET_CHAR_BIT);
> +  set_gdbarch_int_bit              (gdbarch, 4 * TARGET_CHAR_BIT);
> +  set_gdbarch_long_bit             (gdbarch, 4 * TARGET_CHAR_BIT);
> +  set_gdbarch_long_long_bit        (gdbarch, 8 * TARGET_CHAR_BIT);
> +  set_gdbarch_float_bit            (gdbarch, 4 * TARGET_CHAR_BIT);
> +  set_gdbarch_double_bit           (gdbarch, 8 * TARGET_CHAR_BIT);
> +  set_gdbarch_long_double_bit      (gdbarch, 8 * TARGET_CHAR_BIT);
> +  set_gdbarch_float_format         (gdbarch, & floatformat_ieee_single_big);
> +  set_gdbarch_double_format        (gdbarch, & floatformat_ieee_double_big);
> +  set_gdbarch_long_double_format   (gdbarch, & floatformat_ieee_double_big);
> +  set_gdbarch_return_value	   (gdbarch, iq2000_return_value);
> +  set_gdbarch_breakpoint_from_pc   (gdbarch, iq2000_breakpoint_from_pc);
> +  set_gdbarch_frame_args_skip      (gdbarch, 0);
> +  set_gdbarch_skip_prologue        (gdbarch, iq2000_skip_prologue);
> +  set_gdbarch_decr_pc_after_break  (gdbarch, 0);
> +  set_gdbarch_inner_than           (gdbarch, core_addr_lessthan);
> +  set_gdbarch_print_insn           (gdbarch, print_insn_iq2000);
> +  set_gdbarch_register_type (gdbarch, iq2000_register_type);
> +  set_gdbarch_frame_align (gdbarch, iq2000_frame_align);
> +  set_gdbarch_unwind_sp (gdbarch, iq2000_unwind_sp);
> +  set_gdbarch_unwind_pc (gdbarch, iq2000_unwind_pc);
> +  set_gdbarch_unwind_dummy_id (gdbarch, iq2000_unwind_dummy_id);
> +  frame_base_set_default (gdbarch, &iq2000_frame_base);
> +  set_gdbarch_push_dummy_call (gdbarch, iq2000_push_dummy_call);
> +
> +  gdbarch_init_osabi (info, gdbarch);
> +
> +  frame_unwind_append_sniffer (gdbarch, dwarf2_frame_sniffer);
> +  frame_unwind_append_sniffer (gdbarch, iq2000_frame_sniffer);
> +
> +  return gdbarch;
> +}

I think all the calls to set_gdbarch_<type>_bit can be left out,
because they just re-state the default values.  Same for
decr_pc_after_break, no?

+static enum return_value_convention
+iq2000_return_value (struct gdbarch *gdbarch, struct type *type,
+		     struct regcache *regcache,
+		     void *readbuf, const void *writebuf)
+{
+  if (iq2000_use_struct_convention (type))
+    return RETURN_VALUE_STRUCT_CONVENTION;
+  if (writebuf)
+    iq2000_store_return_value (type, regcache, writebuf);
+  else if (readbuf)
+    iq2000_extract_return_value (type, regcache, readbuf);
+  return RETURN_VALUE_REGISTER_CONVENTION;
+}

The other return_value implementations I've seen allow one to pass
both a readbuf and a writebuf, and do the read before the write.  I
can't find any place where it's actually used this way, but it seems
to be allowed by the interface.  In any case, it's easy enough to make
iq2000_return_value behave like the others.

Re: [RFA] New GDB target iq2000

[Daniel Jacobowitz]

On Tue, Mar 01, 2005 at 05:11:31PM -0500, Jim Blandy wrote:
> +static enum return_value_convention
> +iq2000_return_value (struct gdbarch *gdbarch, struct type *type,
> +		     struct regcache *regcache,
> +		     void *readbuf, const void *writebuf)
> +{
> +  if (iq2000_use_struct_convention (type))
> +    return RETURN_VALUE_STRUCT_CONVENTION;
> +  if (writebuf)
> +    iq2000_store_return_value (type, regcache, writebuf);
> +  else if (readbuf)
> +    iq2000_extract_return_value (type, regcache, readbuf);
> +  return RETURN_VALUE_REGISTER_CONVENTION;
> +}
> 
> The other return_value implementations I've seen allow one to pass
> both a readbuf and a writebuf, and do the read before the write.  I
> can't find any place where it's actually used this way, but it seems
> to be allowed by the interface.  In any case, it's easy enough to make
> iq2000_return_value behave like the others.

I'd rather leave it this way, and find somewhere to document that you
mustn't pass both.  It doesn't make much sense to have them both...

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: [RFA] New GDB target iq2000

[Corinna Vinschen]

Hi Jim,

On Mar  1 17:11, Jim Blandy wrote:
> I think all the calls to set_gdbarch_<type>_bit can be left out,
> because they just re-state the default values.  Same for
> decr_pc_after_break, no?

I'm ok with removing decr_pc_after_break, but I'd rather leave the
set_..._bit calls in, so that one can see on the first glance how
the datatypes are defined for this target.  Actually I'd prefer to
have them defined in all targets explicitely.  That way, a casual
reader of the code doesn't have to guess if the programmer left
them out accidentally or deliberately, especially in border cases
as long long or long double.

> +static enum return_value_convention
> +iq2000_return_value (struct gdbarch *gdbarch, struct type *type,
> [...]
> 
> The other return_value implementations I've seen allow one to pass
> both a readbuf and a writebuf, and do the read before the write.  I
> can't find any place where it's actually used this way, but it seems
> to be allowed by the interface.  In any case, it's easy enough to make
> iq2000_return_value behave like the others.

I'm with Daniel here.  readbuf and writebuf are mutually exclusive,
at least from a logical point of view.  If the order of requesting
the value of readbuf and writebuf changes the behaviour of the
gdbarch_return_value function, than that's a design flaw of
gdbarch_return_value and should be fixed.


Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat, Inc.

Re: [RFA] New GDB target iq2000

[Daniel Jacobowitz]

On Tue, Feb 22, 2005 at 12:41:41PM +0100, Corinna Vinschen wrote:
> Hi,
> 
> this posting contributes the iq2000 code for GDB.
> 
> There's just one problem with it.  Older GCC code (older than two days,
> actually), emits an asymmetrical register numbering in the dwarf2 debugging
> output.  The iq2000 uses register 31 as link register, which contains the
> return address to the calling function.  For some reason GCC emitted the
> register number 26 in the dwarf2 information for this register.  Every
> other register has been used unchanged in dwarf2, so there was no
> unambiguous translation from dwarf2 register numbers to real register
> numbers, if the dwarf2 register was "26".  This has been fixed yesterday
> in GCC HEAD.
> 
> As a result, the dwarf2 frame sniffer has a problem with code generated
> by GCC's older than two days.  This is no problem for the iq2000 frame
> sniffer implemented in iq2000-tdep.c, but as usual, the iq2000 frame
> sniffer is appended after the dwarf2 frame sniffer:
> 
>     frame_unwind_append_sniffer (gdbarch, dwarf2_frame_sniffer);
>     frame_unwind_append_sniffer (gdbarch, iq2000_frame_sniffer);
> 
> Would that be a good reason to disable the dwarf2 frame sniffer for now?
> Or shall I leave that as is?

It's up to you; I think leaving it as is and writing off the problem as
a broken compiler will probably be good enough for the iq2000 userbase.
If it isn't, we can come back to the problem later.

It looks good to me, but I have one concern.  You've got
find_last_line_symbol:

> +/* Function: find_last_line_symbol
> +
> +   Given an address range, first find a line symbol corresponding to
> +   the starting address.  Then find the last line symbol within the 
> +   range that has a line number less than or equal to the first line.
> +
> +   For optimized code with code motion, this finds the last address
> +   for the lowest-numbered line within the address range.  */

And you've got this too:

> +static CORE_ADDR
> +iq2000_skip_prologue (CORE_ADDR pc)
> +{
> +  CORE_ADDR func_addr = 0 , func_end = 0;
> +
> +  if (find_pc_partial_function (pc, NULL, & func_addr, & func_end))
> +    {
> +      struct symtab_and_line sal;
> +      struct iq2000_frame_cache cache;
> +
> +      /* Found a function.  */
> +      sal = find_pc_line (func_addr, 0);
> +      if (sal.end && sal.end < func_end)
> +	/* Found a line number, use it as end of prologue.  */
> +	return sal.end;
> +
> +      /* No useable line symbol.  Use prologue parsing method.  */
> +      iq2000_init_frame_cache (&cache);
> +      return iq2000_scan_prologue (func_addr, func_end, NULL, &cache);
> +    }
> +
> +  /* No function symbol -- just return the PC.  */
> +  return (CORE_ADDR) pc;
> +}

I'm trying to cut down on the proliferation of linetable-aware code in
tdep files.  We've already got skip_prologue_using_sal, which is
similar but not quite the same.  Will that work for iq2000?  Failing
that, should the new method be used on other targets?  There's nothing
iq2000 specific about it.


-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: [RFA] New GDB target iq2000

[Kevin Buettner]

On Thu, 3 Mar 2005 12:34:43 -0500
Daniel Jacobowitz <drow@false.org> wrote:

> I'm trying to cut down on the proliferation of linetable-aware code in
> tdep files.  We've already got skip_prologue_using_sal, which is
> similar but not quite the same.  Will that work for iq2000?  Failing
> that, should the new method be used on other targets?  There's nothing
> iq2000 specific about it.

IMO, skip_prologue_using_sal() either needs to be rewritten or deleted.
In its present form, it's not very useful.

Kevin

Re: [RFA] New GDB target iq2000

[Daniel Jacobowitz]

On Thu, Mar 03, 2005 at 10:46:29AM -0700, Kevin Buettner wrote:
> On Thu, 3 Mar 2005 12:34:43 -0500
> Daniel Jacobowitz <drow@false.org> wrote:
> 
> > I'm trying to cut down on the proliferation of linetable-aware code in
> > tdep files.  We've already got skip_prologue_using_sal, which is
> > similar but not quite the same.  Will that work for iq2000?  Failing
> > that, should the new method be used on other targets?  There's nothing
> > iq2000 specific about it.
> 
> IMO, skip_prologue_using_sal() either needs to be rewritten or deleted.
> In its present form, it's not very useful.

FWIW, I have a small modification to it which lets it handle two
consecutive line notes at the same address (it's still in my queue). 
After that, it was quite useful on ARM.

If the generic version is not very useful, let's see what we can do
about that!  Could you elaborate?

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: [RFA] New GDB target iq2000

[Kevin Buettner]

On Thu, 3 Mar 2005 12:51:33 -0500
Daniel Jacobowitz <drow@false.org> wrote:

> On Thu, Mar 03, 2005 at 10:46:29AM -0700, Kevin Buettner wrote:
> > On Thu, 3 Mar 2005 12:34:43 -0500
> > Daniel Jacobowitz <drow@false.org> wrote:
> > 
> > > I'm trying to cut down on the proliferation of linetable-aware code in
> > > tdep files.  We've already got skip_prologue_using_sal, which is
> > > similar but not quite the same.  Will that work for iq2000?  Failing
> > > that, should the new method be used on other targets?  There's nothing
> > > iq2000 specific about it.
> > 
> > IMO, skip_prologue_using_sal() either needs to be rewritten or deleted.
> > In its present form, it's not very useful.
> 
> FWIW, I have a small modification to it which lets it handle two
> consecutive line notes at the same address (it's still in my queue). 
> After that, it was quite useful on ARM.
> 
> If the generic version is not very useful, let's see what we can do
> about that!  Could you elaborate?

I haven't done a recent anaylsis, but I did one a while back.  See:

    http://sources.redhat.com/ml/gdb-patches/2004-08/msg00043.html

Kevin

Re: [RFA] New GDB target iq2000

[Corinna Vinschen]

On Mar  3 12:34, Daniel Jacobowitz wrote:
> On Tue, Feb 22, 2005 at 12:41:41PM +0100, Corinna Vinschen wrote:
> > As a result, the dwarf2 frame sniffer has a problem with code generated
> > by GCC's older than two days.  This is no problem for the iq2000 frame
> > sniffer implemented in iq2000-tdep.c, but as usual, the iq2000 frame
> > sniffer is appended after the dwarf2 frame sniffer:
> > 
> >     frame_unwind_append_sniffer (gdbarch, dwarf2_frame_sniffer);
> >     frame_unwind_append_sniffer (gdbarch, iq2000_frame_sniffer);
> > 
> > Would that be a good reason to disable the dwarf2 frame sniffer for now?
> > Or shall I leave that as is?
> 
> It's up to you; I think leaving it as is and writing off the problem as
> a broken compiler will probably be good enough for the iq2000 userbase.
> If it isn't, we can come back to the problem later.

Sounds like a plan to me.

> It looks good to me, but I have one concern.  You've got
> find_last_line_symbol:
> 
> > +/* Function: find_last_line_symbol
> > +
> > +   Given an address range, first find a line symbol corresponding to
> > +   the starting address.  Then find the last line symbol within the 
> > +   range that has a line number less than or equal to the first line.
> > +
> > +   For optimized code with code motion, this finds the last address
> > +   for the lowest-numbered line within the address range.  */

What's your exact concern with this function?  It's just used inside
of the iq2000 prologue scanner to decide if the scanning loop should
break or continue.

> And you've got this too:
> 
> > +static CORE_ADDR
> > +iq2000_skip_prologue (CORE_ADDR pc)
> > +{
> > +  CORE_ADDR func_addr = 0 , func_end = 0;
> > +
> > +  if (find_pc_partial_function (pc, NULL, & func_addr, & func_end))
> > +    {
> > +      struct symtab_and_line sal;
> > +      struct iq2000_frame_cache cache;
> > +
> > +      /* Found a function.  */
> > +      sal = find_pc_line (func_addr, 0);
> > +      if (sal.end && sal.end < func_end)
> > +	/* Found a line number, use it as end of prologue.  */
> > +	return sal.end;
> > +
> > +      /* No useable line symbol.  Use prologue parsing method.  */
> > +      iq2000_init_frame_cache (&cache);
> > +      return iq2000_scan_prologue (func_addr, func_end, NULL, &cache);
> > +    }
> > +
> > +  /* No function symbol -- just return the PC.  */
> > +  return (CORE_ADDR) pc;
> > +}
> 
> I'm trying to cut down on the proliferation of linetable-aware code in
> tdep files.  We've already got skip_prologue_using_sal, which is
> similar but not quite the same.  Will that work for iq2000?  Failing
> that, should the new method be used on other targets?  There's nothing
> iq2000 specific about it.

Except for calling iq2000_scan_prologue, a function which is entirely
internal to the iq2000 code and not available through the gdbarch framework.

I'm sorry, but the reason for getting rid of linetable-aware code is
somewhat beyond me.  I'll happily do something else, as far as it's
available and works, but using skip_prologue_using_sal is really no
option here.

Any chance I can apply the code, after removing the
set_gdbarch_decr_pc_after_break call?


Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat, Inc.

Re: [RFA] New GDB target iq2000

[Daniel Jacobowitz]

On Fri, Mar 04, 2005 at 10:46:05AM +0100, Corinna Vinschen wrote:
> What's your exact concern with this function?  It's just used inside
> of the iq2000 prologue scanner to decide if the scanning loop should
> break or continue.

> Except for calling iq2000_scan_prologue, a function which is entirely
> internal to the iq2000 code and not available through the gdbarch framework.

[Of course, I meant the rest of the function, not that bit!]

> I'm sorry, but the reason for getting rid of linetable-aware code is
> somewhat beyond me.

Because _there is nothing architecture specific about what you are
doing_.  Therefore, most likely, it is either right for all platforms
or wrong for this one.  I want to understand which.  If it's right for
all platforms, I'd like it to live in common code so that we can
maintain it for all platforms.

>  I'll happily do something else, as far as it's
> available and works, but using skip_prologue_using_sal is really no
> option here.

Why?  Is it the same problem Kevin described?  As I wrote, I have
successfully used this function on other architectures.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: [RFA] New GDB target iq2000

[Corinna Vinschen]

On Mar  4 09:14, Daniel Jacobowitz wrote:
> On Fri, Mar 04, 2005 at 10:46:05AM +0100, Corinna Vinschen wrote:
> > I'm sorry, but the reason for getting rid of linetable-aware code is
> > somewhat beyond me.
> 
> Because _there is nothing architecture specific about what you are
> doing_.  Therefore, most likely, it is either right for all platforms
> or wrong for this one.  I want to understand which.  If it's right for
> all platforms, I'd like it to live in common code so that we can
> maintain it for all platforms.

The platform specific part is to call iq2000_scan_prologue if the
line number information is bogus.

> >  I'll happily do something else, as far as it's
> > available and works, but using skip_prologue_using_sal is really no
> > option here.
> 
> Why?  Is it the same problem Kevin described?  As I wrote, I have
> successfully used this function on other architectures.

I haven't exactly analyzed the situation so far, but using
skip_prologue_using_sal results in three more FAILs in the testsuite:

  FAIL: gdb.base/break.exp: breakpoint small function, optimized file
  FAIL: gdb.base/break.exp: run until breakpoint set at small function, optimized file
  FAIL: gdb.base/nodebug.exp: running to inner in runto

All three cases don't look like simple coincidence.  In all three cases
we suffer from either optimized code or unavailable debug information.
The target specific "knowledge", which is represented by the call to
iq2000_scan_prologue helps to master this situation.


Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat, Inc.

Re: [RFA] New GDB target iq2000

[Daniel Jacobowitz]

On Fri, Mar 04, 2005 at 04:01:29PM +0100, Corinna Vinschen wrote:
> On Mar  4 09:14, Daniel Jacobowitz wrote:
> > On Fri, Mar 04, 2005 at 10:46:05AM +0100, Corinna Vinschen wrote:
> > > I'm sorry, but the reason for getting rid of linetable-aware code is
> > > somewhat beyond me.
> > 
> > Because _there is nothing architecture specific about what you are
> > doing_.  Therefore, most likely, it is either right for all platforms
> > or wrong for this one.  I want to understand which.  If it's right for
> > all platforms, I'd like it to live in common code so that we can
> > maintain it for all platforms.
> 
> The platform specific part is to call iq2000_scan_prologue if the
> line number information is bogus.
> 
> > >  I'll happily do something else, as far as it's
> > > available and works, but using skip_prologue_using_sal is really no
> > > option here.
> > 
> > Why?  Is it the same problem Kevin described?  As I wrote, I have
> > successfully used this function on other architectures.
> 
> I haven't exactly analyzed the situation so far, but using
> skip_prologue_using_sal results in three more FAILs in the testsuite:
> 
>   FAIL: gdb.base/break.exp: breakpoint small function, optimized file
>   FAIL: gdb.base/break.exp: run until breakpoint set at small function, optimized file
>   FAIL: gdb.base/nodebug.exp: running to inner in runto
> 
> All three cases don't look like simple coincidence.  In all three cases
> we suffer from either optimized code or unavailable debug information.
> The target specific "knowledge", which is represented by the call to
> iq2000_scan_prologue helps to master this situation.

Would you mind posting disassembly, line table (readelf -wl), and GDB
transcript for these failures?

I'm not trying to block the inclusion of the iq2000 port, but I would
like to make sure we understand this problem before we include a
workaround.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: [RFA] New GDB target iq2000

[Corinna Vinschen]

On Mar  4 10:06, Daniel Jacobowitz wrote:
> On Fri, Mar 04, 2005 at 04:01:29PM +0100, Corinna Vinschen wrote:
> > All three cases don't look like simple coincidence.  In all three cases
> > we suffer from either optimized code or unavailable debug information.
> > The target specific "knowledge", which is represented by the call to
> > iq2000_scan_prologue helps to master this situation.
> 
> Would you mind posting disassembly, line table (readelf -wl), and GDB
> transcript for these failures?

Sure.  First the both break.exp fails, which are interlocked:

FAIL: gdb.base/break.exp: breakpoint small function, optimized file
FAIL: gdb.base/break.exp: run until breakpoint set at small function, optimized file

- Disassembly of function marker4:

  80000368 <marker4>:
  80000368:       27 bd ff f0     addiu r29,r29,0xfff0

  8000036c <$LCFI9>:
  8000036c:       af bb 00 08     sw r27,0x8(r29)

  80000370 <$LCFI10>:
  80000370:       00 1d d8 25     or r27,r0,r29

  80000374 <$LCFI11>:
  80000374:       af 64 00 00     sw r4,0x0(r27)

  80000378 <$LM8>:
  80000378:       00 1b e8 25     or r29,r0,r27
  8000037c:       8f bb 00 08     lw r27,0x8(r29)
  80000380:       00 00 00 00     nop
  80000384:       27 bd 00 10     addiu r29,r29,0x10
  80000388:       03 e0 00 08     jr r31
  8000038c:       00 00 00 00     nop

- Line table for file break1.c:

  Line Number Statements:
    Extended opcode 2: set Address to 0x800002e8
    Special opcode 49: advance Address by 0 to 0x800002e8 and Line by 39 to 40
    Extended opcode 2: set Address to 0x800002f4
    Copy
    Extended opcode 2: set Address to 0x80000310
    Special opcode 11: advance Address by 0 to 0x80000310 and Line by 1 to 41
    Extended opcode 2: set Address to 0x80000320
    Copy
    Extended opcode 2: set Address to 0x8000033c
    Special opcode 11: advance Address by 0 to 0x8000033c and Line by 1 to 42
    Extended opcode 2: set Address to 0x80000350
    Copy
    Extended opcode 2: set Address to 0x80000368
    Special opcode 11: advance Address by 0 to 0x80000368 and Line by 1 to 43
    Extended opcode 2: set Address to 0x80000378
    Copy
    Extended opcode 2: set Address to 0x80000390
    Extended opcode 1: End of Sequence

- GDB testsuite result with iq2000_skip_prologue:

  break marker4^M 
  Breakpoint 2 at 0x800001f0: file testsuite/gdb.base/break1.c, line 43.^M
  (gdb) PASS: gdb.base/break.exp: breakpoint small function, optimized file
  run^M 
  Starting program: testsuite/gdb.base/breako2 ^M
  ^M
  Breakpoint 1, main (argc=0, argv=0x0, envp=0x0) at testsuite/gdb.base/break.c:85^M
  85      {^M
  (gdb) PASS: gdb.base/break.exp: run until function breakpoint, optimized file (code motion) 
  continue^M
  Continuing.^M
  720^M
  ^M
  Breakpoint 2, marker4 (d=177601976) at testsuite/gdb.base/break1.c:43^M
  43      void marker4 (d) long d; {}             /* set breakpoint 13 here */^M
  PASS: gdb.base/break.exp: run until breakpoint set at small function, optimized file

- GDB testsuite result with skip_prologue_using_sal:

  break marker4^M
  Breakpoint 2 at 0x800001f8^M
  (gdb) FAIL: gdb.base/break.exp: breakpoint small function, optimized file
  run^M
  Starting program: testsuite/gdb.base/breako2 ^M
  ^M
  Breakpoint 1, main (argc=0, argv=0x0, envp=0x0) at testsuite/gdb.base/break.c:85^M
  85      {^M 
  (gdb) PASS: gdb.base/break.exp: run until function breakpoint, optimized file (code motion)
  continue^M
  Continuing.^M
  720^M
  ^M
  Breakpoint 2, 0x800001f8 in write_int ()^M
  (gdb) FAIL: gdb.base/break.exp: run until breakpoint set at small function, optimized file


Now the nodebug.exp case:

FAIL: gdb.base/nodebug.exp: running to inner in runto

- Disassembly of function inner:

  80000048 <inner>:
  80000048:       27 bd ff f0     addiu r29,r29,0xfff0
  8000004c:       af bb 00 08     sw r27,0x8(r29)
  80000050:       00 1d d8 25     or r27,r0,r29
  80000054:       af 64 00 00     sw r4,0x0(r27)
  80000058:       3c 02 00 00     lui r2,0x0
  8000005c:       8f 63 00 00     lw r3,0x0(r27)
  80000060:       8c 42 10 00     lw r2,0x1000(r2)
  80000064:       00 00 00 00     nop
  80000068:       00 62 10 21     addu r2,r3,r2
  8000006c:       3c 03 00 00     lui r3,0x0
  80000070:       8c 63 10 04     lw r3,0x1004(r3)
  80000074:       00 00 00 00     nop
  80000078:       00 43 10 21     addu r2,r2,r3
  8000007c:       3c 03 00 00     lui r3,0x0
  80000080:       8c 63 19 b4     lw r3,0x19b4(r3)
  80000084:       00 00 00 00     nop
  80000088:       00 43 10 21     addu r2,r2,r3
  8000008c:       3c 03 00 00     lui r3,0x0
  80000090:       8c 63 19 74     lw r3,0x1974(r3)
  80000094:       00 00 00 00     nop
  80000098:       00 43 10 21     addu r2,r2,r3
  8000009c:       00 1b e8 25     or r29,r0,r27
  800000a0:       8f bb 00 08     lw r27,0x8(r29)
  800000a4:       00 00 00 00     nop
  800000a8:       27 bd 00 10     addiu r29,r29,0x10
  800000ac:       03 e0 00 08     jr r31

- Line table for file nodebug.c:

  There is none since nodebug.c is compiled without -g

- GDB testsuite result with iq2000_skip_prologue:

  (gdb) file testsuite/gdb.base/nodebug^M
  Reading symbols from testsuite/gdb.base/nodebug...done.^M
  (gdb) target sim ^M
  Connected to the simulator.^M
  (gdb) load^M
  Loading section .text, size 0x3858 lma 0x80000000^M
  Loading section .data, size 0x7e0 lma 0x1000^M
  Loading section .eh_frame, size 0x118 lma 0x17e0^M
  Loading section .rodata, size 0x7c lma 0x18f8^M
  Start address 0x80000000^M
  Transfer rate: 134752 bits in <1 sec.^M
  (gdb) delete breakpoints^M
  (gdb) info breakpoints^M
  No breakpoints or watchpoints.^M
  (gdb) break inner^M
  Breakpoint 1 at 0x80000058^M
  (gdb) target sim ^M
  Connected to the simulator.^M
  (gdb) load^M
  Loading section .text, size 0x3858 lma 0x80000000^M
  Loading section .data, size 0x7e0 lma 0x1000^M
  Loading section .eh_frame, size 0x118 lma 0x17e0^M
  Loading section .rodata, size 0x7c lma 0x18f8^M
  Start address 0x80000000^M
  Transfer rate: 134752 bits in <1 sec.^M
  (gdb) run ^M
  Starting program: testsuite/gdb.base/nodebug ^M
  ^M
  Breakpoint 1, 0x80000058 in inner ()^M

- GDB testsuite result with skip_prologue_using_sal:

  (gdb) file testsuite/gdb.base/nodebug^M
  Reading symbols from testsuite/gdb.base/nodebug...done.^M
  (gdb) target sim ^M 
  Connected to the simulator.^M
  (gdb) load^M
  Loading section .text, size 0x3858 lma 0x80000000^M
  Loading section .data, size 0x7e0 lma 0x1000^M
  Loading section .eh_frame, size 0x118 lma 0x17e0^M 
  Loading section .rodata, size 0x7c lma 0x18f8^M
  Start address 0x80000000^M
  Transfer rate: 134752 bits in <1 sec.^M
  (gdb) delete breakpoints^M
  (gdb) info breakpoints^M
  No breakpoints or watchpoints.^M
  (gdb) break inner^M
  Breakpoint 1 at 0x0^M
  (gdb) target sim ^M
  Connected to the simulator.^M
  (gdb) load^M
  Loading section .text, size 0x3858 lma 0x80000000^M
  Loading section .data, size 0x7e0 lma 0x1000^M
  Loading section .eh_frame, size 0x118 lma 0x17e0^M
  Loading section .rodata, size 0x7c lma 0x18f8^M 
  Start address 0x80000000^M
  Transfer rate: 134752 bits in <1 sec.^M
  (gdb) run ^M
  Starting program: testsuite/gdb.base/nodebug ^M
  ^M
  *** EXIT code 28^M
  ^M
  Program exited with code 034.^M
  (gdb) FAIL: gdb.base/nodebug.exp: running to inner in runto

Note especially the `break inner' which sets a breakpoint to address 0.


Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat, Inc.

Re: [RFA] New GDB target iq2000

[Daniel Jacobowitz]

On Fri, Mar 04, 2005 at 04:51:27PM +0100, Corinna Vinschen wrote:
> On Mar  4 10:06, Daniel Jacobowitz wrote:
> > On Fri, Mar 04, 2005 at 04:01:29PM +0100, Corinna Vinschen wrote:
> > > All three cases don't look like simple coincidence.  In all three cases
> > > we suffer from either optimized code or unavailable debug information.
> > > The target specific "knowledge", which is represented by the call to
> > > iq2000_scan_prologue helps to master this situation.
> > 
> > Would you mind posting disassembly, line table (readelf -wl), and GDB
> > transcript for these failures?
> 
> Sure.  First the both break.exp fails, which are interlocked:

Thanks!  I don't quite grok this bit:

> - Disassembly of function marker4:
> 
>   80000368 <marker4>:
>   80000368:       27 bd ff f0     addiu r29,r29,0xfff0



>   break marker4^M 
>   Breakpoint 2 at 0x800001f0: file testsuite/gdb.base/break1.c, line 43.^M

The PCs don't match - I haven't been able to work out how the one
input produced the other output yet.

Let me try something different, which will hopefully waste less of your
time.  Could you mail me the two binaries, and the patch to use
skip_prologue_using_sal?  I can build an iq2000 GDB easily enough; I
just don't want to set up an entire iq2000 toolchain.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: [RFA] New GDB target iq2000

[Daniel Jacobowitz]

On Fri, Mar 04, 2005 at 04:01:29PM +0100, Corinna Vinschen wrote:
> On Mar  4 09:14, Daniel Jacobowitz wrote:
> > On Fri, Mar 04, 2005 at 10:46:05AM +0100, Corinna Vinschen wrote:
> > > I'm sorry, but the reason for getting rid of linetable-aware code is
> > > somewhat beyond me.
> > 
> > Because _there is nothing architecture specific about what you are
> > doing_.  Therefore, most likely, it is either right for all platforms
> > or wrong for this one.  I want to understand which.  If it's right for
> > all platforms, I'd like it to live in common code so that we can
> > maintain it for all platforms.
> 
> The platform specific part is to call iq2000_scan_prologue if the
> line number information is bogus.
> 
> > >  I'll happily do something else, as far as it's
> > > available and works, but using skip_prologue_using_sal is really no
> > > option here.
> > 
> > Why?  Is it the same problem Kevin described?  As I wrote, I have
> > successfully used this function on other architectures.
> 
> I haven't exactly analyzed the situation so far, but using
> skip_prologue_using_sal results in three more FAILs in the testsuite:
> 
>   FAIL: gdb.base/break.exp: breakpoint small function, optimized file
>   FAIL: gdb.base/break.exp: run until breakpoint set at small function, optimized file
>   FAIL: gdb.base/nodebug.exp: running to inner in runto
> 
> All three cases don't look like simple coincidence.  In all three cases
> we suffer from either optimized code or unavailable debug information.
> The target specific "knowledge", which is represented by the call to
> iq2000_scan_prologue helps to master this situation.

Could you try the attached patch, which explains what I meant?

I left the other function alone.  skip_prologue_using_sal is already a
bit bogus, for the reasons identified by Kevin as well as for at least
one other that I can see.  find_last_line_symbol is even boguser. 
Basically, any code that compares the LINE member of two arbitrary SALs
_must_ be wrong.  They don't even need to be in the same source file.

There's two things that GDB uses the guessed prologue line information
for.  One is to place an initial breakpoint, so that the arguments have
been saved.  This problem will hopefully eventually go away, with
improved GCC -fvar-tracking - we should be able to print the arguments
from anywhere.  Someone needs to spend a little love on the compiler
side of this.

The other is as a limit for prologue scanners.  IMO, what you need in
iq2000_scan_prologue is not line table data at all, but a list of
instructions which can not be considered part of the prologue. 
Basically that is calls and branches, and a check that you only record
a register save the first time you see the register being saved.
Going too far here is not a major problem; after the patch below, I
think the call in iq2000_skip_prologue is basically redundant. 
Returning FUNC_ADDR would work just about as well, since if we have no
line data, we probably have no symbolic argument information either.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Index: src/gdb/iq2000-tdep.c
===================================================================
--- src.orig/gdb/iq2000-tdep.c	2005-03-04 16:05:39.000000000 -0500
+++ src/gdb/iq2000-tdep.c	2005-03-04 16:39:49.000000000 -0500
@@ -335,20 +335,17 @@ iq2000_init_frame_cache (struct iq2000_f
 static CORE_ADDR
 iq2000_skip_prologue (CORE_ADDR pc)
 {
-  CORE_ADDR func_addr = 0 , func_end = 0;
+  CORE_ADDR func_addr = 0, func_end = 0, ret;
+
+  ret = skip_prologue_using_sal (pc);
+  if (ret)
+    return max (ret, pc);
 
   if (find_pc_partial_function (pc, NULL, & func_addr, & func_end))
     {
-      struct symtab_and_line sal;
       struct iq2000_frame_cache cache;
 
-      /* Found a function.  */
-      sal = find_pc_line (func_addr, 0);
-      if (sal.end && sal.end < func_end)
-	/* Found a line number, use it as end of prologue.  */
-	return sal.end;
-
-      /* No useable line symbol.  Use prologue parsing method.  */
+      /* Found a function.  Use prologue parsing method.  */
       iq2000_init_frame_cache (&cache);
       return iq2000_scan_prologue (func_addr, func_end, NULL, &cache);
     }

Re: [RFA] New GDB target iq2000

[Mark Kettenis]

   Date: Fri, 4 Mar 2005 17:01:04 -0500
   From: Daniel Jacobowitz <drow@false.org>

   I left the other function alone.  skip_prologue_using_sal is already a
   bit bogus, for the reasons identified by Kevin as well as for at least
   one other that I can see.  find_last_line_symbol is even boguser. 
   Basically, any code that compares the LINE member of two arbitrary SALs
   _must_ be wrong.  They don't even need to be in the same source file.

Another issue with skip_prologue_using_sal() is that it will happily
skip the entire function if the function body is basically empty.  I
really think it should be deprecated, and shouldn't be used in any new
code.

   There's two things that GDB uses the guessed prologue line information
   for.  One is to place an initial breakpoint, so that the arguments have
   been saved.  This problem will hopefully eventually go away, with
   improved GCC -fvar-tracking - we should be able to print the arguments
   from anywhere.  Someone needs to spend a little love on the compiler
   side of this.

The important thing about placing the initial breakpoint, is that it
shouldn't be placed too far into the function.  In particular it
should not end up after a branch instruction.

   The other is as a limit for prologue scanners.  IMO, what you need in
   iq2000_scan_prologue is not line table data at all, but a list of
   instructions which can not be considered part of the prologue. 
   Basically that is calls and branches, and a check that you only record
   a register save the first time you see the register being saved.
   Going too far here is not a major problem; after the patch below, I
   think the call in iq2000_skip_prologue is basically redundant. 
   Returning FUNC_ADDR would work just about as well, since if we have no
   line data, we probably have no symbolic argument information either.

Most prologue scanners indeed "know" about what conditions end a
prologue.  In those cases the limit is only there to prevent the
analyzer to run away if for some reason it ends up analyzing code that
it shouldn't.

Mark

Re: [RFA] New GDB target iq2000

[Daniel Jacobowitz]

On Sat, Mar 05, 2005 at 12:28:53PM +0100, Mark Kettenis wrote:
>    Date: Fri, 4 Mar 2005 17:01:04 -0500
>    From: Daniel Jacobowitz <drow@false.org>
> 
>    I left the other function alone.  skip_prologue_using_sal is already a
>    bit bogus, for the reasons identified by Kevin as well as for at least
>    one other that I can see.  find_last_line_symbol is even boguser. 
>    Basically, any code that compares the LINE member of two arbitrary SALs
>    _must_ be wrong.  They don't even need to be in the same source file.
> 
> Another issue with skip_prologue_using_sal() is that it will happily
> skip the entire function if the function body is basically empty.  I
> really think it should be deprecated, and shouldn't be used in any new
> code.

Hum... so it will.  I rather think it should be fixed.  I have a patch
to fix the most common occurance of that, when the line notes look
like:
	line1:
	line2:
		ret

For a compiler which doesn't use the two line note convention, of
course, it's bogus - but so is lots of the rest of GDB.

Could you explain why you think it should be deprecated?  Bear in mind
that it's _new_ - it was derived from various similar things in tdep
files, in an attempt to commonize.

>    There's two things that GDB uses the guessed prologue line information
>    for.  One is to place an initial breakpoint, so that the arguments have
>    been saved.  This problem will hopefully eventually go away, with
>    improved GCC -fvar-tracking - we should be able to print the arguments
>    from anywhere.  Someone needs to spend a little love on the compiler
>    side of this.
> 
> The important thing about placing the initial breakpoint, is that it
> shouldn't be placed too far into the function.  In particular it
> should not end up after a branch instruction.

Yes.  I mentioned to Kevin off-list that I've been thinking about an
ideal paradigm for implementing both this and prologue scanners.  What
we need is a common simulator architecture which can "describe" the
effects of instructions - enough instructions to handle prologues, at
least.  A huge project for someday :-)

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: [RFA] New GDB target iq2000

[Mark Kettenis]

   Date: Sat, 5 Mar 2005 11:44:52 -0500
   From: Daniel Jacobowitz <drow@false.org>

   On Sat, Mar 05, 2005 at 12:28:53PM +0100, Mark Kettenis wrote:
   >    Date: Fri, 4 Mar 2005 17:01:04 -0500
   >    From: Daniel Jacobowitz <drow@false.org>
   > 
   >    I left the other function alone.  skip_prologue_using_sal is already a
   >    bit bogus, for the reasons identified by Kevin as well as for at least
   >    one other that I can see.  find_last_line_symbol is even boguser. 
   >    Basically, any code that compares the LINE member of two arbitrary SALs
   >    _must_ be wrong.  They don't even need to be in the same source file.
   > 
   > Another issue with skip_prologue_using_sal() is that it will happily
   > skip the entire function if the function body is basically empty.  I
   > really think it should be deprecated, and shouldn't be used in any new
   > code.

   Hum... so it will.  I rather think it should be fixed.  I have a patch
   to fix the most common occurance of that, when the line notes look
   like:
	   line1:
	   line2:
		   ret

   For a compiler which doesn't use the two line note convention, of
   course, it's bogus - but so is lots of the rest of GDB.

That's not an excuse for not trying to come up with an algorithm
that's more robust.  Attached is the patch that I have sitting in my
tree.

   Could you explain why you think it should be deprecated?  Bear in mind
   that it's _new_ - it was derived from various similar things in tdep
   files, in an attempt to commonize.

And it was never properly tested.  And there was never a coordinated
attempt to use this common code.

   >    There's two things that GDB uses the guessed prologue line information
   >    for.  One is to place an initial breakpoint, so that the arguments have
   >    been saved.  This problem will hopefully eventually go away, with
   >    improved GCC -fvar-tracking - we should be able to print the arguments
   >    from anywhere.  Someone needs to spend a little love on the compiler
   >    side of this.
   > 
   > The important thing about placing the initial breakpoint, is that it
   > shouldn't be placed too far into the function.  In particular it
   > should not end up after a branch instruction.

   Yes.  I mentioned to Kevin off-list that I've been thinking about an
   ideal paradigm for implementing both this and prologue scanners.  What
   we need is a common simulator architecture which can "describe" the
   effects of instructions - enough instructions to handle prologues, at
   least.  A huge project for someday :-)

That suggestion has been made more than once in the past; I don't
really consider this viable for architectures where instructions
aren't fixed length.

Anyway, I think most problems are caused because we are trying to use
the same code for two distinct cases: (a) getting an upper limit for
the prologue end and (b) getting a lower limit for the prologue end.
Combining (a) and (b) results in having to determine the end of the
prologue exactly, which is much harder.

Mark


Index: symtab.c
===================================================================
RCS file: /cvs/src/src/gdb/symtab.c,v
retrieving revision 1.144
diff -u -p -r1.144 symtab.c
--- symtab.c 15 Feb 2005 15:49:21 -0000 1.144
+++ symtab.c 5 Mar 2005 18:12:51 -0000
@@ -4050,6 +4050,11 @@ skip_prologue_using_sal (CORE_ADDR func_
 	  prologue_sal = sal;
 	}
     }
+
+  /* Avoid skipping the entire function.  */
+  if (prologue_sal.end >= end_pc)
+    return 0;
+
   return prologue_sal.end;
 }
 \f

Re: [RFA] New GDB target iq2000

[Daniel Jacobowitz]

On Sat, Mar 05, 2005 at 07:13:12PM +0100, Mark Kettenis wrote:
> That's not an excuse for not trying to come up with an algorithm
> that's more robust.  Attached is the patch that I have sitting in my
> tree.

This looks like an obvious fix to me.

>    Could you explain why you think it should be deprecated?  Bear in mind
>    that it's _new_ - it was derived from various similar things in tdep
>    files, in an attempt to commonize.
> 
> And it was never properly tested.  And there was never a coordinated
> attempt to use this common code.

Yes.  I'm hoping to expand use of it, which will improve test coverage,
and Kevin has an analysis of another problem with it which should be
fixed.

>    >    There's two things that GDB uses the guessed prologue line information
>    >    for.  One is to place an initial breakpoint, so that the arguments have
>    >    been saved.  This problem will hopefully eventually go away, with
>    >    improved GCC -fvar-tracking - we should be able to print the arguments
>    >    from anywhere.  Someone needs to spend a little love on the compiler
>    >    side of this.
>    > 
>    > The important thing about placing the initial breakpoint, is that it
>    > shouldn't be placed too far into the function.  In particular it
>    > should not end up after a branch instruction.
> 
>    Yes.  I mentioned to Kevin off-list that I've been thinking about an
>    ideal paradigm for implementing both this and prologue scanners.  What
>    we need is a common simulator architecture which can "describe" the
>    effects of instructions - enough instructions to handle prologues, at
>    least.  A huge project for someday :-)
> 
> That suggestion has been made more than once in the past; I don't
> really consider this viable for architectures where instructions
> aren't fixed length.

Could you explain why that particular property makes a difference?

I'm not talking about an ultra-specialized "simulator" the way that
current GDB prologue analyzers work; I'm talking about most of a
complete architecture simulator, with appropriate hooks to tell GDB
what it wants to know.  There's plenty of other ways we could use this
information.

Here's one I've been thinking about in particular: some instructions
are "safe" to simulate on a running process, though not all.  When a
breakpoint covers an instruction which is "safe", we can simulate the
instruction instead of having to remove the breakpoint and single-step. 
Huge win with threads.

> Anyway, I think most problems are caused because we are trying to use
> the same code for two distinct cases: (a) getting an upper limit for
> the prologue end and (b) getting a lower limit for the prologue end.
> Combining (a) and (b) results in having to determine the end of the
> prologue exactly, which is much harder.

Just checking, but first-line breakpoints should go at the lower limit
and scanning until the upper limit - is that right?

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: [RFA] New GDB target iq2000

[Mark Kettenis]

   Date: Sat, 5 Mar 2005 14:37:39 -0500
   From: Daniel Jacobowitz <drow@false.org>

   > That suggestion has been made more than once in the past; I don't
   > really consider this viable for architectures where instructions
   > aren't fixed length.

   Could you explain why that particular property makes a difference?

Makes it difficult to ignore instructions; GDB has to know the length
of them in order to skip them.

   Here's one I've been thinking about in particular: some instructions
   are "safe" to simulate on a running process, though not all.  When a
   breakpoint covers an instruction which is "safe", we can simulate the
   instruction instead of having to remove the breakpoint and single-step. 
   Huge win with threads.

Yikes!  Well if it helps...

   > Anyway, I think most problems are caused because we are trying to use
   > the same code for two distinct cases: (a) getting an upper limit for
   > the prologue end and (b) getting a lower limit for the prologue end.
   > Combining (a) and (b) results in having to determine the end of the
   > prologue exactly, which is much harder.

   Just checking, but first-line breakpoints should go at the lower limit
   and scanning until the upper limit - is that right?

Yup.  Although the lower-limit for first-line breakpoints may cause
bogus parameter values to be printed.  I consider that less a problem
than my program unexpectedly running to completion though.  The
problem is that some people tend to think differently and we never
reached consensus about it.

Mark

Re: [RFA] New GDB target iq2000

[Daniel Jacobowitz]

On Sat, Mar 05, 2005 at 09:17:45PM +0100, Mark Kettenis wrote:
>    Date: Sat, 5 Mar 2005 14:37:39 -0500
>    From: Daniel Jacobowitz <drow@false.org>
> 
>    > That suggestion has been made more than once in the past; I don't
>    > really consider this viable for architectures where instructions
>    > aren't fixed length.
> 
>    Could you explain why that particular property makes a difference?
> 
> Makes it difficult to ignore instructions; GDB has to know the length
> of them in order to skip them.

Trivial, even in the existing framework - ask the disassembler.  A
complete GDB port may not have a simulator, let alone my hypothetical
uber-simulator, but it will definitely have a disassembler.

>    > Anyway, I think most problems are caused because we are trying to use
>    > the same code for two distinct cases: (a) getting an upper limit for
>    > the prologue end and (b) getting a lower limit for the prologue end.
>    > Combining (a) and (b) results in having to determine the end of the
>    > prologue exactly, which is much harder.
> 
>    Just checking, but first-line breakpoints should go at the lower limit
>    and scanning until the upper limit - is that right?
> 
> Yup.  Although the lower-limit for first-line breakpoints may cause
> bogus parameter values to be printed.  I consider that less a problem
> than my program unexpectedly running to completion though.  The
> problem is that some people tend to think differently and we never
> reached consensus about it.

Well, it makes sense to me.  It's clear that the FRV and submitted
iq2000 ports have different heuristics for these two cases; it would be
good to cover both of them in common code.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: [RFA] New GDB target iq2000

[Corinna Vinschen]

On Mar  5 15:20, Daniel Jacobowitz wrote:
> On Sat, Mar 05, 2005 at 09:17:45PM +0100, Mark Kettenis wrote:
> > Yup.  Although the lower-limit for first-line breakpoints may cause
> > bogus parameter values to be printed.  I consider that less a problem
> > than my program unexpectedly running to completion though.  The
> > problem is that some people tend to think differently and we never
> > reached consensus about it.
> 
> Well, it makes sense to me.  It's clear that the FRV and submitted
> iq2000 ports have different heuristics for these two cases; it would be
> good to cover both of them in common code.

This is rather getting a generic discussion to me.  What about the
iq2000 port itself?  Does it make sense to defer iq2000 until after
the generic problem has been solved?


Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat, Inc.

Re: [RFA] New GDB target iq2000

[Daniel Jacobowitz]

On Mon, Mar 07, 2005 at 11:08:35AM +0100, Corinna Vinschen wrote:
> On Mar  5 15:20, Daniel Jacobowitz wrote:
> > On Sat, Mar 05, 2005 at 09:17:45PM +0100, Mark Kettenis wrote:
> > > Yup.  Although the lower-limit for first-line breakpoints may cause
> > > bogus parameter values to be printed.  I consider that less a problem
> > > than my program unexpectedly running to completion though.  The
> > > problem is that some people tend to think differently and we never
> > > reached consensus about it.
> > 
> > Well, it makes sense to me.  It's clear that the FRV and submitted
> > iq2000 ports have different heuristics for these two cases; it would be
> > good to cover both of them in common code.
> 
> This is rather getting a generic discussion to me.  What about the
> iq2000 port itself?  Does it make sense to defer iq2000 until after
> the generic problem has been solved?

No, it doesn't.  Did you see the patch I sent you on Friday night?

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: [RFA] New GDB target iq2000

[Corinna Vinschen]

On Mar  7 09:03, Daniel Jacobowitz wrote:
> On Mon, Mar 07, 2005 at 11:08:35AM +0100, Corinna Vinschen wrote:
> > On Mar  5 15:20, Daniel Jacobowitz wrote:
> > > On Sat, Mar 05, 2005 at 09:17:45PM +0100, Mark Kettenis wrote:
> > > > Yup.  Although the lower-limit for first-line breakpoints may cause
> > > > bogus parameter values to be printed.  I consider that less a problem
> > > > than my program unexpectedly running to completion though.  The
> > > > problem is that some people tend to think differently and we never
> > > > reached consensus about it.
> > > 
> > > Well, it makes sense to me.  It's clear that the FRV and submitted
> > > iq2000 ports have different heuristics for these two cases; it would be
> > > good to cover both of them in common code.
> > 
> > This is rather getting a generic discussion to me.  What about the
> > iq2000 port itself?  Does it make sense to defer iq2000 until after
> > the generic problem has been solved?
> 
> No, it doesn't.  Did you see the patch I sent you on Friday night?

I've tried it and it has two FAILs more than the original version of
iq2000_skip_prologue, the two break.exp FAILs we already know:

  (gdb) FAIL: gdb.base/break.exp: breakpoint small function, optimized file
  (gdb) FAIL: gdb.base/break.exp: run until breakpoint set at small function, optimized file


Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat, Inc.

Re: [RFA] New GDB target iq2000

[Daniel Jacobowitz]

On Mon, Mar 07, 2005 at 09:17:08PM +0100, Corinna Vinschen wrote:
> On Mar  7 09:03, Daniel Jacobowitz wrote:
> > On Mon, Mar 07, 2005 at 11:08:35AM +0100, Corinna Vinschen wrote:
> > > On Mar  5 15:20, Daniel Jacobowitz wrote:
> > > > On Sat, Mar 05, 2005 at 09:17:45PM +0100, Mark Kettenis wrote:
> > > > > Yup.  Although the lower-limit for first-line breakpoints may cause
> > > > > bogus parameter values to be printed.  I consider that less a problem
> > > > > than my program unexpectedly running to completion though.  The
> > > > > problem is that some people tend to think differently and we never
> > > > > reached consensus about it.
> > > > 
> > > > Well, it makes sense to me.  It's clear that the FRV and submitted
> > > > iq2000 ports have different heuristics for these two cases; it would be
> > > > good to cover both of them in common code.
> > > 
> > > This is rather getting a generic discussion to me.  What about the
> > > iq2000 port itself?  Does it make sense to defer iq2000 until after
> > > the generic problem has been solved?
> > 
> > No, it doesn't.  Did you see the patch I sent you on Friday night?
> 
> I've tried it and it has two FAILs more than the original version of
> iq2000_skip_prologue, the two break.exp FAILs we already know:
> 
>   (gdb) FAIL: gdb.base/break.exp: breakpoint small function, optimized file
>   (gdb) FAIL: gdb.base/break.exp: run until breakpoint set at small function, optimized file

Just a guess but - this is probably because you sent me "break" rather
than "breako2", the actual optimized binary.  May I have another shot
at it?

In the mean time, this is drawing out too long; I'm going to review the
port without attention to this issue this afternoon.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: [RFA] New GDB target iq2000

[Daniel Jacobowitz]

On Sat, Mar 05, 2005 at 02:37:39PM -0500, Daniel Jacobowitz wrote:
> I'm not talking about an ultra-specialized "simulator" the way that
> current GDB prologue analyzers work; I'm talking about most of a
> complete architecture simulator, with appropriate hooks to tell GDB
> what it wants to know.  There's plenty of other ways we could use this
> information.
> 
> Here's one I've been thinking about in particular: some instructions
> are "safe" to simulate on a running process, though not all.  When a
> breakpoint covers an instruction which is "safe", we can simulate the
> instruction instead of having to remove the breakpoint and single-step. 
> Huge win with threads.

It occured to me (late, but better than never) that generating this
sort of thing from a CGEN description would not be too hard... for
someone who spoke Scheme, anyway.

Not that I'm volunteering to write the missing cgen descriptions.
But it would be an interesting experiment for one of the five ports
that already have one (cris, frv, iq2000, m32r, sh).

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: [RFA] New GDB target iq2000

[Daniel Jacobowitz]

On Tue, Feb 22, 2005 at 12:41:41PM +0100, Corinna Vinschen wrote:
> Hi,
> 
> this posting contributes the iq2000 code for GDB.
> 
> There's just one problem with it.  Older GCC code (older than two days,
> actually), emits an asymmetrical register numbering in the dwarf2 debugging
> output.  The iq2000 uses register 31 as link register, which contains the
> return address to the calling function.  For some reason GCC emitted the
> register number 26 in the dwarf2 information for this register.  Every
> other register has been used unchanged in dwarf2, so there was no
> unambiguous translation from dwarf2 register numbers to real register
> numbers, if the dwarf2 register was "26".  This has been fixed yesterday
> in GCC HEAD.
> 
> As a result, the dwarf2 frame sniffer has a problem with code generated
> by GCC's older than two days.  This is no problem for the iq2000 frame
> sniffer implemented in iq2000-tdep.c, but as usual, the iq2000 frame
> sniffer is appended after the dwarf2 frame sniffer:
> 
>     frame_unwind_append_sniffer (gdbarch, dwarf2_frame_sniffer);
>     frame_unwind_append_sniffer (gdbarch, iq2000_frame_sniffer);
> 
> Would that be a good reason to disable the dwarf2 frame sniffer for now?
> Or shall I leave that as is?

This is OK; I'll handle the linetable issues separately.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: [RFA] New GDB target iq2000

[Corinna Vinschen]

On Mar  7 15:37, Daniel Jacobowitz wrote:
> On Mon, Mar 07, 2005 at 09:17:08PM +0100, Corinna Vinschen wrote:
> > I've tried it and it has two FAILs more than the original version of
> > iq2000_skip_prologue, the two break.exp FAILs we already know:
> > 
> >   (gdb) FAIL: gdb.base/break.exp: breakpoint small function, optimized file
> >   (gdb) FAIL: gdb.base/break.exp: run until breakpoint set at small function, optimized file
> 
> Just a guess but - this is probably because you sent me "break" rather
> than "breako2", the actual optimized binary.  May I have another shot
> at it?

Sure.  Shall I send breako2 to you via PM?


Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat, Inc.

Re: [RFA] New GDB target iq2000

[Corinna Vinschen]

On Mar  7 16:35, Daniel Jacobowitz wrote:
> On Tue, Feb 22, 2005 at 12:41:41PM +0100, Corinna Vinschen wrote:
> > Hi,
> > 
> > this posting contributes the iq2000 code for GDB.
> > 
> > There's just one problem with it.  Older GCC code (older than two days,
> > actually), emits an asymmetrical register numbering in the dwarf2 debugging
> > output.  The iq2000 uses register 31 as link register, which contains the
> > return address to the calling function.  For some reason GCC emitted the
> > register number 26 in the dwarf2 information for this register.  Every
> > other register has been used unchanged in dwarf2, so there was no
> > unambiguous translation from dwarf2 register numbers to real register
> > numbers, if the dwarf2 register was "26".  This has been fixed yesterday
> > in GCC HEAD.
> > 
> > As a result, the dwarf2 frame sniffer has a problem with code generated
> > by GCC's older than two days.  This is no problem for the iq2000 frame
> > sniffer implemented in iq2000-tdep.c, but as usual, the iq2000 frame
> > sniffer is appended after the dwarf2 frame sniffer:
> > 
> >     frame_unwind_append_sniffer (gdbarch, dwarf2_frame_sniffer);
> >     frame_unwind_append_sniffer (gdbarch, iq2000_frame_sniffer);
> > 
> > Would that be a good reason to disable the dwarf2 frame sniffer for now?
> > Or shall I leave that as is?
> 
> This is OK; I'll handle the linetable issues separately.

Thanks, applied.


Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat, Inc.

Re: [RFA] New GDB target iq2000

[Daniel Jacobowitz]

On Tue, Mar 08, 2005 at 10:00:36AM +0100, Corinna Vinschen wrote:
> On Mar  7 15:37, Daniel Jacobowitz wrote:
> > On Mon, Mar 07, 2005 at 09:17:08PM +0100, Corinna Vinschen wrote:
> > > I've tried it and it has two FAILs more than the original version of
> > > iq2000_skip_prologue, the two break.exp FAILs we already know:
> > > 
> > >   (gdb) FAIL: gdb.base/break.exp: breakpoint small function, optimized file
> > >   (gdb) FAIL: gdb.base/break.exp: run until breakpoint set at small function, optimized file
> > 
> > Just a guess but - this is probably because you sent me "break" rather
> > than "breako2", the actual optimized binary.  May I have another shot
> > at it?
> 
> Sure.  Shall I send breako2 to you via PM?

Yes, please.

-- 
Daniel Jacobowitz
CodeSourcery, LLC