This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: gdb 5.0: solib.c (LM_ADDR) should be signed, not unsigned
- To: Andrew Cagney <ac131313 at cygnus dot com>
- Subject: Re: gdb 5.0: solib.c (LM_ADDR) should be signed, not unsigned
- From: Michael Snyder <msnyder at redhat dot com>
- Date: Wed, 26 Jul 2000 12:28:17 -0700
- CC: "Maciej W. Rozycki" <macro at ds2 dot pg dot gda dot pl>, gdb-patches at sourceware dot cygnus dot com
- Organization: Red Hat, Inc.
- References: <Pine.GSO.3.96.1000724141721.27187H-100000@delta.ds2.pg.gda.pl> <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