public inbox for insight-prs@sourceware.org
help / color / mirror / Atom feed
From: "Haji, Faizal \[Cont\]" <Faizal.Haji@gdcanada.com>
To: kseitz@sources.redhat.com
Cc: insight-prs@sources.redhat.com,
Subject: RE: insight/170: Assembly windows display .long 0 for remote targ ets
Date: Thu, 29 Aug 2002 11:53:00 -0000 [thread overview]
Message-ID: <20020829185301.11652.qmail@sources.redhat.com> (raw)
The following reply was made to PR insight/170; it has been noted by GNATS.
From: "Haji, Faizal [Cont]" <Faizal.Haji@gdcanada.com>
To: "'kseitz@sources.redhat.com'" <kseitz@sources.redhat.com>,
"Haji, Faizal [Cont]" <Faizal.Haji@gdcanada.com>,
"'insight-prs@sources.redhat.com'" <insight-prs@sources.redhat.com>,
"'kseitz@sources.redhat.com'" <kseitz@sources.redhat.com>,
"'nobody@sources.redhat.com'" <nobody@sources.redhat.com>,
"'insight-gnats@sources.redhat.com'" <insight-gnats@sources.redhat.com>
Cc:
Subject: RE: insight/170: Assembly windows display .long 0 for remote targ
ets
Date: Thu, 29 Aug 2002 12:43:04 -0600
>$ powerpc-eabi-gdb -nw -nx -q foo.elf
> (gdb) disassemble DeleteChar
>
> Does it also show ".long 0x0"? If not, I'll need a testcase from you.
No. The correct disassembly is displayed.
BTW, our executable is built such that the code exists in ROM but gets
copied over to RAM on bootup. The symbols in the ELF file point to the code
in RAM and NOT ROM. There is no executable code in the RAM region within the
ELF file.
I think there should be a mode within Insight to read instructions from
target and not the executable file.
This problem is not a priority for us since the developers are using the
non-GUI version of GDB under Emacs (I guess you can't teach old dogs new
tricks).
-----Original Message-----
From: kseitz@sources.redhat.com [mailto:kseitz@sources.redhat.com]
Sent: Wednesday, August 28, 2002 6:11 PM
To: faizal.haji@gdcanada.com; insight-prs@sources.redhat.com;
kseitz@sources.redhat.com; nobody@sources.redhat.com
Subject: Re: insight/170: Assembly windows display .long 0 for remote
targets
Synopsis: Assembly windows display .long 0 for remote targets
Responsible-Changed-From-To: unassigned->kseitz
Responsible-Changed-By: kseitz
Responsible-Changed-When: Wed Aug 28 17:11:22 2002
Responsible-Changed-Why:
mine
State-Changed-From-To: open->analyzed
State-Changed-By: kseitz
State-Changed-When: Wed Aug 28 17:11:22 2002
State-Changed-Why:
There could be any number of problems here.
The command line/console window use different mechanisms to do the
disassembly: the Source Window reads instructions from the executable file,
while the console will read from the target. What happens if you do:
$ powerpc-eabi-gdb -nw -nx -q foo.elf
(gdb) disassemble DeleteChar
Does it also show ".long 0x0"? If not, I'll need a testcase from you.
http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&databas
e=insight&pr=170
reply other threads:[~2002-08-29 18:53 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20020829185301.11652.qmail@sources.redhat.com \
--to=faizal.haji@gdcanada.com \
--cc=insight-prs@sources.redhat.com \
--cc=kseitz@sources.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).