All of lore.kernel.org
 help / color / mirror / Atom feed
From: Randolph Chung <randolph@tausq.org>
To: John David Anglin <dave@hiauly1.hia.nrc.ca>
Cc: parisc-linux@lists.parisc-linux.org
Subject: Re: [parisc-linux] Latest 2.6.13-rc6-pa2 test pr :_(
Date: Thu, 25 Aug 2005 23:59:17 +0800	[thread overview]
Message-ID: <430DEAD5.9070008@tausq.org> (raw)
In-Reply-To: <200508241530.j7OFUFwS005854@hiauly1.hia.nrc.ca>

> Still don't know.  I have been working on the java testsuite which
> appears to cause most of the kernel bugs.  I fixed a bug last weekend
> where the signal handler caused a SIGSEGV.  An incorrect count was
> used to copy a mmapped block.  We still have a problem with PR218.exe.
> The DWARF unwind fails to stop and allocates a huge amount of memory.
> PR218 is a simple test to test whether the runtime can catch a null
> pointer exception from a leaf routine.  I think there is a bug in
> MD_FALLBACK_FRAME_STATE_FOR.  It replaces the %r2 value with the
> iaoq[0] value and I think this fails when we need to unwind through
> a leaf function which doesn't save %r2.

Can you explain more where this is broken?

I'm assuming you are talking about this bit of code:

     134   fs->regs.reg[2].how = REG_SAVED_OFFSET;
     135   fs->regs.reg[2].loc.offset = (long) &sc->sc_iaoq[0] - new_cfa;
     136   fs->retaddr_column = 2;

sc_iaoq[0] should be the pc when the signal handler was triggered, so it 
shouldn't matter if it's a leaf func or not. We are simply telling the 
unwinder that reg[2] has the return address of the current (signal 
handler) function, and the value of reg[2] can be computed with a stack 
offset. When is this wrong?

randolph
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

       reply	other threads:[~2005-08-25 15:59 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200508241530.j7OFUFwS005854@hiauly1.hia.nrc.ca>
2005-08-25 15:59 ` Randolph Chung [this message]
2005-08-25 17:04   ` [parisc-linux] Latest 2.6.13-rc6-pa2 test pr :_( John David Anglin
     [not found] <200508261342.j7QDgMCk015398@hiauly1.hia.nrc.ca>
2005-08-27 14:40 ` Randolph Chung
2005-08-27 17:38   ` John David Anglin
2005-08-26 16:18 Joel Soete
     [not found] <ILU3F9$C3BA108CF7E2FE4DECDD367F36FD15E5@scarlet.be>
2005-08-26 15:29 ` John David Anglin
     [not found] <4305FA88.9040404@tausq.org>
2005-08-19 18:41 ` John David Anglin
2005-08-20 17:51 ` John David Anglin
2005-08-21 14:37   ` Joel Soete
2005-08-21 15:47     ` John David Anglin
2005-08-21 15:53   ` Randolph Chung
2005-08-21 16:46     ` John David Anglin
  -- strict thread matches above, loose matches on Subject: below --
2005-08-18 16:01 Joel Soete
2005-08-18 17:24 ` John David Anglin
2005-08-18 23:49 ` Randolph Chung

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=430DEAD5.9070008@tausq.org \
    --to=randolph@tausq.org \
    --cc=dave@hiauly1.hia.nrc.ca \
    --cc=parisc-linux@lists.parisc-linux.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.