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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.