Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Michael Snyder <msnyder@redhat.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>,
	gdb-patches@sourceware.cygnus.com
Subject: Re: gdb 5.0: solib.c (LM_ADDR) should be signed, not unsigned
Date: Wed, 26 Jul 2000 15:49:00 -0000	[thread overview]
Message-ID: <397F3BD1.7E7F@redhat.com> (raw)
In-Reply-To: <397E6840.F0F99FA1@cygnus.com>

Andrew Cagney wrote:
> 
> "Maciej W. Rozycki" wrote:
> >
> > Hi,
> >
> >  It appeared not only LM_ADDR has problems with signedness.  Here is an
> > updated patch that fixes read_register() as well.
> >
> 
> > diff -u --recursive --new-file gdb-5.0.macro/gdb/solib.c gdb-5.0/gdb/solib.c
> > --- gdb-5.0.macro/gdb/solib.c   Wed Apr  5 20:40:22 2000
> > +++ gdb-5.0/gdb/solib.c Sun Jul 23 23:16:32 2000
> > @@ -117,10 +117,12 @@
> >
> >  #define SOLIB_EXTRACT_ADDRESS(member) \
> >    extract_address (&member, sizeof (member))
> > +#define SOLIB_EXTRACT_SIGNED_ADDRESS(member) \
> > +  extract_signed_address (&member, sizeof (member))
> >
> >  #ifndef SVR4_SHARED_LIBS
> >
> > -#define LM_ADDR(so) (SOLIB_EXTRACT_ADDRESS ((so) -> lm.lm_addr))
> > +#define LM_ADDR(so) (SOLIB_EXTRACT_SIGNED_ADDRESS ((so) -> lm.lm_addr))
> >  #define LM_NEXT(so) (SOLIB_EXTRACT_ADDRESS ((so) -> lm.lm_next))
> >  #define LM_NAME(so) (SOLIB_EXTRACT_ADDRESS ((so) -> lm.lm_name))
> >  /* Test for first link map entry; first entry is a shared library. */
> > @@ -133,7 +135,7 @@
> >
> >  #else /* SVR4_SHARED_LIBS */
> >
> > -#define LM_ADDR(so) (SOLIB_EXTRACT_ADDRESS ((so) -> lm.l_addr))
> > +#define LM_ADDR(so) (SOLIB_EXTRACT_SIGNED_ADDRESS ((so) -> lm.l_addr))
> >  #define LM_NEXT(so) (SOLIB_EXTRACT_ADDRESS ((so) -> lm.l_next))
> >  #define LM_NAME(so) (SOLIB_EXTRACT_ADDRESS ((so) -> lm.l_name))
> >  /* Test for first link map entry; first entry is the exec-file. */
> 
> I don't think this is right.  I think it would sign extend that address
> for all targets - wrong in 99% of cases.

By the way, I will shortly be submitting changes that 
make all these macros into functions.  Should I do it
sooner rather than later?  Will that help at all?


> Can you provide more information on the problem you're seeing (+
> host/target etc).
> 
>         Andrew



  parent reply	other threads:[~2000-07-26 15:49 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <Pine.GSO.3.96.1000619191851.10348S-100000@delta.ds2.pg.gda.pl>
2000-07-24  5:23 ` Maciej W. Rozycki
     [not found]   ` <397E6840.F0F99FA1@cygnus.com>
2000-07-26 15:49     ` Michael Snyder [this message]
2000-07-26 17:53       ` 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=397F3BD1.7E7F@redhat.com \
    --to=msnyder@redhat.com \
    --cc=ac131313@cygnus.com \
    --cc=gdb-patches@sourceware.cygnus.com \
    --cc=macro@ds2.pg.gda.pl \
    /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