Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Randolph Chung <randolph@tausq.org>
To: gdb-patches@sources.redhat.com
Subject: Re: [patch/rfa] tweak patterns for annota3.exp
Date: Mon, 06 Dec 2004 03:03:00 -0000	[thread overview]
Message-ID: <20041206025645.GY6359@tausq.org> (raw)
In-Reply-To: <20041206024904.GA30704@nevyn.them.org>

> Are you sure there's nothing but an extra \r\n?  It definitely passes
> for others, so I'd like to know where that came from.

yup... the log says:

signal SIGUSR1^M
^M
^Z^Zpost-prompt^M
Continuing with signal SIGUSR1.^M
^M
^Z^Zstarting^M
^M
^Z^Zframes-invalid^M
^M
^Z^Zbreakpoint 2^M
^M
Breakpoint 2, 0x000105d4 in handle_USR1 (sig=16) at /home/tausq/gdb/gdb-cvs/gdb/testsuite/gdb.base/annota3.c:18^M
^M
^Z^Zsource /home/tausq/gdb/gdb-cvs/gdb/testsuite/gdb.base/annota3.c:18:238:beg:0x105d4^M
^M
^Z^Zstopped^M
^M
^Z^Zpre-prompt^M
(gdb) ^M
^Z^Zprompt^M
PASS: gdb.base/annota3.exp: send SIGUSR1

i have no idea where that comes from either... 

> > address of the signal handler... i.e. i get 
> > 
> > #0  0x000105d4 in handle_USR1 (sig=16) at /home/tausq/gdb/gdb-cvs/gdb/testsuite/gdb.base/annota3.c:18
> > 
> > instead of what the script expected, which seems to be
> > #0  handle_USR1 (sig=16) at /home/tausq/gdb/gdb-cvs/gdb/testsuite/gdb.base/annota3.c:18
> 
> The extra address means we didn't put the breakpoint at the beginning
> of a line.  This could be a prologue skipper bug, a GCC bug, a general
> the-world-hates-us bug, or we could decide it wasn't a bug.  The
> testsuite seems to contain examples of all of the above.

mmmmm. gcc creates this:

.globl handle_USR1
        .type   handle_USR1, @function
.LFB3:
        .loc 1 18 0
handle_USR1:
        .PROC
        .CALLINFO FRAME=64,NO_CALLS,SAVE_SP,ENTRY_GR=3
        .ENTRY
        copy %r3,%r1
.LCFI0:
        copy %r30,%r3
.LCFI1:
        stwm %r1,64(%r30)
.LCFI2:
        stw %r26,-36(%r3)
        ldo 64(%r3),%r30
        ldwm -64(%r30),%r3
        bv,n %r0(%r2)
        .EXIT
        .PROCEND

we are breakpointing at the ldo insn, which seems to be correct from the
prologue analysis point of view. do you mean that the ".loc" should be
right before the ldo?

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/


  reply	other threads:[~2004-12-06  2:56 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-12-06  2:49 Randolph Chung
2004-12-06  2:56 ` Daniel Jacobowitz
2004-12-06  3:03   ` Randolph Chung [this message]
2004-12-06  3:06     ` Daniel Jacobowitz
2004-12-06  3:27       ` Randolph Chung
2004-12-06 20:52       ` 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=20041206025645.GY6359@tausq.org \
    --to=randolph@tausq.org \
    --cc=gdb-patches@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