[Search for users]
[Overall Top Noters]
[List of all Conferences]
[Download this site]
| Title: | Digital Ladebug debugger |
|
| Moderator: | TLE::LUCIA |
|
| Created: | Fri Feb 28 1992 |
| Last Modified: | Fri Jun 06 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 969 |
| Total number of notes: | 3959 |
856.0. "call_pall bpt being left around" by GEMGRP::PIEPER () Thu Feb 27 1997 17:29
This is with 4.0-30 on unix4.0B. The debugger (or somebody else) isn't quite
fixing up the inserted breakpoints correctly. I will leave the a.out file in
~pieper/gem/stable/ladebug856
gemmin.zko.dec.com:work->decladebug a.out
Welcome to the Ladebug Debugger Version 4.0-30
------------------
object file name: a.out
Reading symbolic information ...done
(ladebug) stopi at 0x120002050
[#1: stopi at 4831846480 ]
(ladebug) stop in main
[#2: stop in void main(void) ]
(ladebug) run
[2] stopped at [main:197 0x120001ffc]
(Cannot find source file for_main.c)
(ladebug) 0x120002050/i
[00012_tst:12, 0x120002050] lda sp, -192(sp)
(ladebug) 0x120002050/10i
[00012_tst:12, 0x120002050] lda sp, -192(sp)
[00012_tst:12, 0x120002054] stq r26, 0(sp)
[00012_tst:12, 0x120002058] stq r9, 8(sp)
[00012_tst:12, 0x12000205c] stq r10, 16(sp)
[00012_tst:12, 0x120002060] stq r11, 24(sp)
[00012_tst:12, 0x120002064] stq r12, 32(sp)
[00012_tst:12, 0x120002068] stq r13, 40(sp)
[00012_tst:12, 0x12000206c] stq r14, 48(sp)
[00012_tst:12, 0x120002070] stq r15, 56(sp)
[00012_tst:12, 0x120002074] bis r31, r1, r13
(ladebug) c
[1] stopped at [00012_tst:12 0x120002050]
12 C$PAR PARALLEL DO LOCAL(i)
(ladebug) 0x120002050/10i
*[00012_tst:12, 0x120002050] lda sp, -192(sp)
[00012_tst:12, 0x120002054] stq r26, 0(sp)
[00012_tst:12, 0x120002058] stq r9, 8(sp)
[00012_tst:12, 0x12000205c] stq r10, 16(sp)
[00012_tst:12, 0x120002060] stq r11, 24(sp)
[00012_tst:12, 0x120002064] stq r12, 32(sp)
[00012_tst:12, 0x120002068] stq r13, 40(sp)
[00012_tst:12, 0x12000206c] stq r14, 48(sp)
[00012_tst:12, 0x120002070] stq r15, 56(sp)
[00012_tst:12, 0x120002074] bis r31, r1, r13
(ladebug) c
[1] stopped at [00012_tst:12 0x120002050]
12 C$PAR PARALLEL DO LOCAL(i)
(ladebug) 0x120002050/10i
*[00012_tst:12, 0x120002050] lda sp, -192(sp)
[00012_tst:12, 0x120002054] call_pal bpt
[00012_tst:12, 0x120002058] stq r9, 8(sp)
[00012_tst:12, 0x12000205c] stq r10, 16(sp)
[00012_tst:12, 0x120002060] stq r11, 24(sp)
[00012_tst:12, 0x120002064] stq r12, 32(sp)
[00012_tst:12, 0x120002068] stq r13, 40(sp)
[00012_tst:12, 0x12000206c] stq r14, 48(sp)
[00012_tst:12, 0x120002070] stq r15, 56(sp)
[00012_tst:12, 0x120002074] bis r31, r1, r13
(ladebug) q
gemmin.zko.dec.com:work->
| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 856.1 | correction; different OS | GEMGRP::PIEPER | | Thu Feb 27 1997 18:21 | 3 |
| gemmin.zko.dec.com:work->cat /etc/motd
Digital UNIX X4.0D-4 (Rev. 667); Fri Feb 21 16:24:08 EST 1997
|
| 856.2 | | TLE::MURRAY | Wanfang Murray | Fri Feb 28 1997 09:50 | 11 |
| Please give o+rx to the image.
We call libmld to disassemble the instruction code. We don't do
it ourselves though.
Wanfang
|
| 856.3 | | GEMGRP::PIEPER | | Fri Feb 28 1997 10:29 | 5 |
| o+rx done.
I think it is more than just a disassembly problem. If I stepi to the call_pal
bpt I get into a bad place. It looks to me like the instructions are actually
changed.
|
| 856.4 | more information | GEMGRP::PIEPER | | Wed Apr 02 1997 10:18 | 46 |
| Peter Craig asked me to file a QAR about this, so I looked at it
again.
I don't think it's worth a QAR, but I'll explain what this note is
about and the ladebug team can decide what to do about it.
At first I thought there was a bug. Maybe it is (see below), or maybe
its just a really annoying distraction.
Here is what I believe is happening:
I set a breakpoint in the image. This is a multi-threaded
application, and some thread is the first to hit the brakpoint. When
it does, if I use "stepi" to move around, more breakpoints are set
and removed. When there is more than one thread around, I can end up
using stepi to get to what I think is the breakpoint trap handler.
The debugger keeps telling me about TRAP signals at any rate.
This is extremely confusing. The debugger should inform the
user when the thread he is looking at has changed. Also, when I use
stepi in single-threaded applications, I never see "call_pal bpt"
instructions left lying around, but I do from a multithreaded
application. The debugger should hide all the modifications it makes
to the source code from the user, regardless of the current thread
context.
Here is David LaFrance-Linden's analysis, which helped me
understand what the debugger does here. Ladebug has some sharp edges
for multithreaded debugging that could use some thought:
I looked quickly at DECLADEBUG::856. I assume this was being
run on an SMP. If so, what ladebug isn't telling you is that
the second stop at 0x120002050 is actually in a second
thread. The 'cont' to the first thread is trying to "single
step over the replaced instruction so it can put back the BPT
before letting it run freely." It is an interesting design
decision (I'll have to think about it) to use a temporary
breakpoint at the next instruction rather than the
machine-single-step facility to accomplish this. So what you
are seeing is that the second thread has stopped, and you are
seeing the temporary breakpoint that is trying to cause the
first thread to stop (so that it can put back the BPT at
0x120002050 and let things run). Managing breakpoints,
continuing, etc, in the face of multiple threads on an SMP is
a real source of headaches, both at the UI level to
specify which of at least three scenarios you want, and at
the debugger implementation level.
|