From: Andrew Cagney <ac131313@cygnus.com>
To: "H . J . Lu" <hjl@lucon.org>
Cc: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>,
Richard Henderson <rth@redhat.com>,
David B Anderson <davea@quasar.engr.sgi.com>,
gdb@sourceware.cygnus.com, binutils@sourceware.cygnus.com
Subject: Re: Why does mips define elf_backend_sign_extend_vma to true?
Date: Wed, 08 Aug 2001 08:18:00 -0000 [thread overview]
Message-ID: <3B71582D.4050003@cygnus.com> (raw)
In-Reply-To: <20010808080306.C26983@lucon.org>
>
>
> Please try
>
> 1. Find a decent compiler for Linux/mips.
> 2. Check out the Linux mips kernel from oss.sgi.com.
> 3. Compile the kernel with -g.
> 4. Compile Linux/mips gdb with 64bit BFD.
> 5. Do
You might need to find a simpler test!
> The problem is the 64bit BFD does the sign extension to the section
> addresses which have the bit 31 set. Gdb cannot find 0x8011c530 in
> those ranges. You may say oh, let's fix gdb to do
>
> (gdb) p printk
> $1 = {int (char *)} 0xffffffff8011c530
>
> I don't think it will be useful to me. I don't think I can set a break
> pount at 0xffffffff8011c530. The sign extension here is only the
> artifact of the 64bit BFD. My mips target is 32bit.
There is a bug but the underlying problem is the oposite of what you
claim. Something is breaking that simple always sign-extend rule
(forgetting to sign extend something) and, as a consequence, the symbol
lookup is failing.
Remember people around here spent years fighting GDB and BFD MIPS
braindamage until someone realised it was all backwards.
Andrew
next prev parent reply other threads:[~2001-08-08 8:18 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-08-07 20:27 David B Anderson
2001-08-07 22:04 ` H . J . Lu
2001-08-07 22:46 ` Richard Henderson
2001-08-07 23:21 ` H . J . Lu
2001-08-08 0:50 ` Richard Henderson
2001-08-08 1:09 ` Maciej W. Rozycki
2001-08-08 7:29 ` H . J . Lu
2001-08-08 7:50 ` Andrew Cagney
2001-08-08 8:03 ` H . J . Lu
2001-08-08 8:18 ` Andrew Cagney [this message]
2001-08-08 9:02 ` H . J . Lu
2001-08-08 9:53 ` Daniel Jacobowitz
2001-08-08 10:02 ` H . J . Lu
2001-08-08 11:02 ` Daniel Jacobowitz
2001-08-08 11:08 ` H . J . Lu
2001-08-09 12:23 ` Andrew Cagney
2001-08-08 9:48 ` Daniel Jacobowitz
2001-08-08 9:52 ` H . J . Lu
2001-08-10 0:47 ` Maciej W. Rozycki
[not found] <20010807182459.A15252@lucon.org>
[not found] ` <20010807183933.A15425@lucon.org>
[not found] ` <3B709900.3000502@cygnus.com>
[not found] ` <20010807184504.A15571@lucon.org>
2001-08-07 18:52 ` H . J . Lu
2001-08-07 18:58 ` Daniel Jacobowitz
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=3B71582D.4050003@cygnus.com \
--to=ac131313@cygnus.com \
--cc=binutils@sourceware.cygnus.com \
--cc=davea@quasar.engr.sgi.com \
--cc=gdb@sourceware.cygnus.com \
--cc=hjl@lucon.org \
--cc=macro@ds2.pg.gda.pl \
--cc=rth@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