From: Paul Mackerras <paulus@cs.anu.edu.au>
To: drow@false.org
Cc: linuxppc-dev@lists.linuxppc.org
Subject: Re: Vger broken w.r.t. gdb
Date: Thu, 29 Jul 1999 14:00:39 +1000 [thread overview]
Message-ID: <199907290400.OAA02618@tango.anu.edu.au> (raw)
In-Reply-To: <19990728222617.A636@them.org> (message from Daniel Jacobowitz on Wed, 28 Jul 1999 22:26:17 -0400)
Daniel Jacobowitz <drow@false.org> wrote:
> After compiling the current vger 2.3.10 (gcc 2.95
> -fno-strict-aliasing), I discovered an odd problem. Strace works just
> fine, but gdb doesn't. Simply 'gdb ls', run it, quit. No processes
> will die but every new process will recieve a SIGTRAP immediately (not
> quite sure if it's before or after the exec() yet). Ignoring SIGTRAP
> seems to make no difference. We're reaching the function
> ProgramCheckException in arch/ppc/kernel/traps.c:
>
> Jul 28 21:07:32 drow kernel: Program check exception at PC: 3000c1a8, SR: 2d032, vector=700
That address looks to be in some shared library. I haven't been using
2.3.x lately (it dies somewhere near `starting crond' on my SMP
powermac), but I would suspect that the ppc ptrace code needs some
work. It looks like gdb is inserting a trap instruction in a shared
library which is going into the in-memory copy of the page rather than
into a copy of the page.
> I don't understand what this is supposed to do. When are program check
> exceptions generated? And most of all, what are those MSR bits? The
The program check exception is generated for various conditions such
as floating-point exceptions, illegal instructions, privileged
instructions in user mode, or trap instructions. On a program check
exception, the CPU copies the MSR into the SRR1 register and then sets
one or more of the high bits of SRR1 to indicate the cause of the
exception. The regs->msr value actually comes from the SRR1 register.
> first one is (1 << 20), or bit 11; this is labeled as Reserved in my
> reference. The second is (1 << 17), or bit 14; this is marked
> Implementation Dependent, and a note adds it is unused on the 601.
You need to look at the SRR1 bit settings for the program check
exception.
Paul.
[[ 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-29 4:00 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 [this message]
1999-07-29 5:38 ` Daniel Jacobowitz
1999-07-29 5:48 ` Paul Mackerras
1999-07-30 5:18 ` Daniel Jacobowitz
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=199907290400.OAA02618@tango.anu.edu.au \
--to=paulus@cs.anu.edu.au \
--cc=Paul.Mackerras@cs.anu.edu.au \
--cc=drow@false.org \
--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).