Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Michael Snyder <msnyder@cygnus.com>
To: gdb-patches@sources.redhat.com, taylor@redhat.com, cagney@redhat.com
Subject: [PATCH] remote protocol support for harvard architecture
Date: Thu, 15 Feb 2001 14:37:00 -0000	[thread overview]
Message-ID: <3A8C5A2A.7808464E@cygnus.com> (raw)

I'll check this in in a day or two.
2001-02-15  Michael Snyder  <msnyder@mvstp600e.cygnus.com>

	* remote.c (build_remote_gdbarch_data): Use new TARGET_ADDR_BIT 
	instead of TARGET_PTR_BIT (to support Harvard architectures).

Index: remote.c
===================================================================
RCS file: /cvs/src/src/gdb/remote.c,v
retrieving revision 1.38
diff -c -3 -p -r1.38 remote.c
*** remote.c	2001/02/08 06:03:53	1.38
--- remote.c	2001/02/15 22:35:26
*************** build_remote_gdbarch_data (void)
*** 5516,5522 ****
  
    /* Cisco stuff */
    tty_input = xmalloc (PBUFSIZ);
!   remote_address_size = TARGET_PTR_BIT;
  }
  
  void
--- 5516,5522 ----
  
    /* Cisco stuff */
    tty_input = xmalloc (PBUFSIZ);
!   remote_address_size = TARGET_ADDR_BIT;
  }
  
  void
From msnyder@cygnus.com Thu Feb 15 14:44:00 2001
From: Michael Snyder <msnyder@cygnus.com>
To: gdb-patches@sources.redhat.com
Cc: jimb@cygnus.com, ezannoni@cygnus.com
Subject: [RFA]: printing symbols with > 32 bit addrs.
Date: Thu, 15 Feb 2001 14:44:00 -0000
Message-id: <3A8C5BDF.97924160@cygnus.com>
X-SW-Source: 2001-02/msg00270.html
Content-length: 1423

 
Oddly enough, info functions seems to fail to print addresses of
non-debugging symbols when addresses are greater than 32 bits.
This patch seems a bit crude, so I'm wondering if anyone has
a better suggestion.
	
2001-02-15  Michael Snyder  <msnyder@mvstp600e.cygnus.com>

	* symtab.c (print_msymbol_info): Print addresses > 32 bits.

Index: symtab.c
===================================================================
RCS file: /cvs/src/src/gdb/symtab.c,v
retrieving revision 1.28
diff -c -3 -p -r1.28 symtab.c
*** symtab.c	2001/01/30 02:49:36	1.28
--- symtab.c	2001/02/15 22:41:21
*************** print_symbol_info (namespace_enum kind, 
*** 2652,2660 ****
  static void
  print_msymbol_info (struct minimal_symbol *msymbol)
  {
!   printf_filtered ("	%08lx  %s\n",
! 		   (unsigned long) SYMBOL_VALUE_ADDRESS (msymbol),
! 		   SYMBOL_SOURCE_NAME (msymbol));
  }
  
  /* This is the guts of the commands "info functions", "info types", and
--- 2652,2665 ----
  static void
  print_msymbol_info (struct minimal_symbol *msymbol)
  {
!   if (TARGET_ADDR_BIT <= 32)
!     printf_filtered ("	%08lx  %s\n",
! 		     (unsigned long) SYMBOL_VALUE_ADDRESS (msymbol),
! 		     SYMBOL_SOURCE_NAME (msymbol));
!   else
!     printf_filtered ("	%016llx  %s\n",
! 		     (LONGEST) SYMBOL_VALUE_ADDRESS (msymbol),
! 		     SYMBOL_SOURCE_NAME (msymbol));
  }
  
  /* This is the guts of the commands "info functions", "info types", and
From taylor@cygnus.com Thu Feb 15 14:48:00 2001
From: David Taylor <taylor@cygnus.com>
To: Michael Elizabeth Chastain <chastain@cygnus.com>
Cc: fnasser@cygnus.com, ac131313@cygnus.com, gdb-patches@sources.redhat.com, keiths@cygnus.com
Subject: Re: [RFA] Assuming malloc exists in callfwmall.exp
Date: Thu, 15 Feb 2001 14:48:00 -0000
Message-id: <200102152248.RAA12420@texas.cygnus.com>
X-SW-Source: 2001-02/msg00271.html
Content-length: 995

    From: Michael Elizabeth Chastain <chastain@cygnus.com>
    Date: Thu, 15 Feb 2001 12:30:03 -0800

    Hi Fernando,

    > And if he/she is a really good maintainer he/she will reject your patch
    > as it would be adding a restriction to inferior function calls that we
    > do not currently have.

    This is bothering me.

    I've seen some real "this is so embarrassing I should wear a brown
    paper bag over my head" bugs:

      (gdb) set input-radix 2
      Input radix now set to decimal 4294967295, hex ffffffff, octal 37777777777.

Umm, that bug only existed in the internal repository, not in the
sources.redhat.com one, only on big endian hosts, and it was due to
the failure to commit a header file change to the internal repository
when the rest of a bug fix was committed.

    Sorry if I make the author of that bug blush.   My point is that this
    happens in software, and that it's the job of the test suite to detect
    when it happens.

Absolutely!

    Michael


             reply	other threads:[~2001-02-15 14:37 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-02-15 14:37 Michael Snyder [this message]
2001-02-15 15:09 ` Andrew Cagney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3A8C5A2A.7808464E@cygnus.com \
    --to=msnyder@cygnus.com \
    --cc=cagney@redhat.com \
    --cc=gdb-patches@sources.redhat.com \
    --cc=taylor@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox