From: Daniel Jacobowitz <drow@false.org>
To: Paul.Mackerras@cs.anu.edu.au
Cc: linuxppc-dev@lists.linuxppc.org
Subject: Re: Vger broken w.r.t. gdb
Date: Fri, 30 Jul 1999 01:18:20 -0400 [thread overview]
Message-ID: <19990730011819.A364@them.org> (raw)
In-Reply-To: <199907290548.PAA02760@tango.anu.edu.au>; from Paul Mackerras on Thu, Jul 29, 1999 at 03:48:59PM +1000
On Thu, Jul 29, 1999 at 03:48:59PM +1000, Paul Mackerras wrote:
> Daniel Jacobowitz <drow@false.org> wrote:
>
> > So my question is, what is at 0x3000c1a8? It would appear, if I am not
> > misreading binfmt_elf.c, to be the program itself in its original
> > mmap'd location. I'm not at all confident of that conclusion, though.
>
> Cat /proc/<pid>/maps while you have the ls process stopped at an
> appropriate point.
>
> > So regs->msr is actually from SRR1 of the running program? Does it
> > generally get stuffed back into the MSR when that task is running?
>
> Yep, but the high bits get ignored.
Now I'm really confused.
>From my readings it appears that we should only reach this point if a
trap instruction was encountered. But from what I can see no trap
instruction exists at that address. At
<http://www.them.org/~drow/check-core> is a core dump I obtained while
my system was in this confusing state; check-test in the same directory
is the program responsible. The instruction appears to be in
_dl_debug_state from what I can tell, but no trap instruction was
present there.
Perhaps something having to do with instruction caching by the
processor? This is a completely wild guess, but if a trap instruction
was encountered, and then gdb cleared it, and the instruction cache was
not flushed...
Dan
/--------------------------------\ /--------------------------------\
| Daniel Jacobowitz |__| SCS Class of 2002 |
| Debian GNU/Linux Developer __ Carnegie Mellon University |
| dan@debian.org | | dmj+@andrew.cmu.edu |
\--------------------------------/ \--------------------------------/
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting. ]]
next prev parent reply other threads:[~1999-07-30 5:18 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-07-29 2:26 Vger broken w.r.t. gdb Daniel Jacobowitz
1999-07-29 4:00 ` Paul Mackerras
1999-07-29 5:38 ` Daniel Jacobowitz
1999-07-29 5:48 ` Paul Mackerras
1999-07-30 5:18 ` Daniel Jacobowitz [this message]
1999-07-30 5:24 ` Paul Mackerras
1999-07-30 6:03 ` Daniel Jacobowitz
1999-07-30 7:07 ` nasty powerpc mmap problems (was: Re: Vger broken w.r.t. gdb) Daniel Jacobowitz
1999-08-02 2:45 ` 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=19990730011819.A364@them.org \
--to=drow@false.org \
--cc=Paul.Mackerras@cs.anu.edu.au \
--cc=linuxppc-dev@lists.linuxppc.org \
/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 NNTP newsgroup(s).