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
next prev 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