Conference turris::decladebug

    The engine has the same limitation:
    
    /local/lucia/scratch> ladebug a.out
    Welcome to the Ladebug Debugger Version 4.0-35
    ------------------ 
    object file name: a.out 
    Reading symbolic information ...done
    (ladebug) W
          1 int main()
          2 {
          3     void foo();
          4 
          5     foo();
          6     printf("bye.\n");
          7 }
          8 
          9 void foo(void)
         10 {
         11     printf("Hi.\n");
         12 }
         13 
    (ladebug) simr
    [#1: stop in int main(void) ]
    [1] stopped at [main:5 0x120001220]
          5     foo();
    (ladebug) s
    stopped at [foo:11 0x120001270]
         11     printf("Hi.\n");
    (ladebug) return
    Hi.
    stopped at [main:5 0x120001228]
          5     foo();
    (ladebug) wi
     [main:2, 0x120001214]  lda     gp, 28288(gp)
     [main:2, 0x120001218]  lda     sp, -16(sp)
     [main:2, 0x12000121c]  stq     r26, 0(sp)
     [main:5, 0x120001220]  ldq     r27, -32672(gp)
     [main:5, 0x120001224]  bsr     r26, foo
    *[main:5, 0x120001228]  ldah    gp, 8192(r26)
     [main:5, 0x12000122c]  lda     gp, 28264(gp)
     [main:6, 0x120001230]  ldq_u   r31, 0(sp)
     [main:6, 0x120001234]  lda     r16, -32768(gp)
     [main:6, 0x120001238]  ldq     r27, -32528(gp)
    (ladebug) 
    
    The explanation is that there is still code from line 5 to be executed,
    so the PC indicator stays on line 5.  Does not mean this is the desired
    behavior, but it is what is happening.
    
    

If the original problem report was as you described in the previous 
reply, Tim, then I would have to agree.  A return exits from the 
current function to the point of invocation, or the return address
to be more precise.  Which leaves you in the cleanup after the 
call which is exactly as intended.  I wouldn't change that.
If however, you are sitting on the last line in a subroutine,
and you do a next or a step, I would consider it an
error to still be on that same line.  The step or next should
take you to the start of the next executable line, which in 
this case should be line 6.  Here's how dbx does it:

petert@deneb 48> dbx foot
dbx version 3.11.12
Type 'help' for help.

main:   5  foo();
(dbx) stop in main
[2] stop in main
(dbx) r
[2] stopped at   [main:5 ,0x1200011a0]  foo();
(dbx) s
  [foo:11 ,0x1200011e8]         printf("Hi.\n");
(dbx) s
Hi.
  [foo:12 ,0x1200011fc]         }
(dbx) s
  [main:6 ,0x1200011b0]         printf("bye.\n");
(dbx) n
bye.
  [main:7 ,0x1200011c8]         }
(dbx) r
[2]   [main:5 ,0x1200011a0]     foo();
(dbx) s
  [foo:11 ,0x1200011e8]         printf("Hi.\n");
(dbx) return
Hi.
  [main:5 +0x8,0x1200011a8]     foo();
(dbx) q


Meanwhile ladebug does this:

petert@deneb 49> ladebug foot
Welcome to the Ladebug Debugger Version 4.0-35
------------------ 
object file name: foot 
Reading symbolic information ...done
(ladebug) stop in main
[#1: stop in int main(void) ]
(ladebug) r
[1] stopped at [main:5 0x1200011a0]
      5     foo();
(ladebug) s
stopped at [foo:11 0x1200011e8]
     11     printf("Hi.\n");
(ladebug) 
Hi.
stopped at [foo:12 0x1200011fc]
     12 }
(ladebug) s
stopped at [main:5 0x1200011a8]
      5     foo();
(ladebug) s
stopped at [main:6 0x1200011b0]
      6     printf("bye.\n");
(ladebug) s
bye.
stopped at [main:7 0x1200011c8]
      7 }
(ladebug) r
[1] stopped at [main:5 0x1200011a0]
      5     foo();
(ladebug) s
stopped at [foo:11 0x1200011e8]
     11     printf("Hi.\n");
(ladebug) return
Hi.
stopped at [main:5 0x1200011a8]
      5     foo();

So the behavior for a step and a return are the same for ladebug
while they are different for dbx.  I'd argue that dbx is a wee bit
more correct in it's behavior here (but then what else would you 
expect of me.)

PeterT

I see your point, subtle as it may be.  The defined behavior is what is
important.  I'm not sure what the defined behavior is.  What happens for 'next'
is that we run forward until the line number changes, which causes us to
'return' to line 5, even though we've returned.

We used to single step until the line number changed, but this was hugely slow
on array operations and such (complex nested loops) so (Shamim, I believe)
someone changed ladebug to hunt down the next instruction which was either a
branch, or on a different line, and set a temporary breakpoint there.

Point here is that ladebug needs to decide which behavior to adopt and make sure
it is clearly documented.  While personally I am used to ladebug taking an extra
step, I think I prefer dbx's behavior.

Tim

Remember to consider the case where a line contains two or more calls.
"s" at the end of the first routine wants to stop at the top of the second
one, doesn't it?  "n" at the end of the first routine wants to stop at the
next line of the caller, right?

    Case of two or more calls on the same line.  Theoreticaslly I agree
    with you.  A step should take you into the next routine, a next
    to the next line.  The way that ladebug treats this, it may
    well do that. 
    Well a quick experiment shows that dbx will step from the end of
    one subroutine into the next, and will next to the next line.
    
    Ladebug will also go into both subroutines with a step,
    but stops in the calling routine first, pretty much as expected.
    
    I was expecting dbx to step to the next line, rather than into the
    next subroutine, but it behaved appropriately.  I guess I've 
    been burned by too many next's that wiped away lots of careful
    debugging  ;-)
    
    PeterT