Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

signatures: generate only one debug breakable line for signatures #22610

Open
wants to merge 1 commit into
base: blead
Choose a base branch
from

Conversation

tonycoz
Copy link
Contributor

@tonycoz tonycoz commented Sep 19, 2024

With the debugger enabled the argcheck op and each argelem op generated to process a function signature would have an associated dbstate op, allowing the debugger to step on that op.

This can be confusing and/or onerous when stepping through code, since for a signature with 7 arguments you'd have 9 steps to get past the prologue of the sub.

Make most of these dbstates into nextstates to make them non-steppable.

Fixes #22602


  • This set of changes requires a perldelta entry, and it is included.
  • This set of changes requires a perldelta entry, and I need help writing it.
  • This set of changes does not require a perldelta entry.

op.h Outdated
@@ -171,6 +171,13 @@ Deprecated. Use C<GIMME_V> instead.
op_convert_list to set op_folded. */
#define OPf_FOLDED (1<<16)

/* force newSTATEOP() to make an OP_NEXTSTATE.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would like to see: "... as opposed to an OP_DBSTATE"

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"make an OP_NEXTSTATE even when in debugging mode and a OP_DBSTATE would normally be produced"

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I reworded it a bit more than that.

print $x1, $x2, $x3, $x4;
}
four(1,2,3,4);
EOS
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I save this heredoc as a separate program, what differences should I be able to observe in the behavior of the debugger between, say, perl-5.40.0 and blead+this patch?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you single-step (s) in the debugger, you should see a lot of invisible statements being executed on the sub four($x1, $x2, $x3, $x4) { line; i.e. you have to repeat s a lot to make the debugger advance into the subroutine.

I haven't tried it, but with this patch I'd assume the debugger only stops once and immediately proceeds to the print in the subroutine body when you hit s.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you single-step (s) in the debugger, you should see a lot of invisible statements being executed on the sub four($x1, $x2, $x3, $x4) { line; i.e. you have to repeat s a lot to make the debugger advance into the subroutine.

I haven't tried it, but with this patch I'd assume the debugger only stops once and immediately proceeds to the print in the subroutine body when you hit s.

Thanks. In perl-5.40.0, It took me 8 s steps before the print statement executed. In the p.r., it only took 3 s steps. LGTM.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Step through the code with "s", pre-patch this steps 6 times on the sub prolog, with patch it steps once

op.h Outdated
@@ -171,6 +171,13 @@ Deprecated. Use C<GIMME_V> instead.
op_convert_list to set op_folded. */
#define OPf_FOLDED (1<<16)

/* force newSTATEOP() to make an OP_NEXTSTATE.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"make an OP_NEXTSTATE even when in debugging mode and a OP_DBSTATE would normally be produced"

@@ -913,7 +913,7 @@ sigscalarelem:
"follows optional parameter");
}

$$ = var ? newSTATEOP(0, NULL, var) : NULL;
$$ = var ? newSTATEOP(OPf_FORCE_NEXTSTATE, NULL, var) : NULL;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This means that in the debugger it now won't be single-steppable even if there is a defaulting expression. It's hard to predict what users might want here, but maybe it's best to keep the DBSTATE if there is a defop? So maybe

defop ? 0 : OPf_FORCE_NEXTSTATE

for the flags?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That would get annoying in the same way as in #22602 if you had more than a couple of default valued arguments.

I think the ideal experience would be to make the debugger display each argument at the signature step points as you step through the signature.

Maybe these breakpoints could be optional, but it would need to be controllable at runtime (ie. need a flag on the dbstate), and I expect discoverability of such an option would be bad.

I'm not sure of a good approach for the debugger to get the variable set by the argelem.

With the debugger enabled the argcheck op and each argelem op
generated to process a function signature would have an associated
dbstate op, allowing the debugger to step on that op.

This can be confusing and/or onerous when stepping through code, since
for a signature with 7 arguments you'd have 9 steps to get past the
prologue of the sub.

Make most of these dbstates into nextstates to make them non-steppable.

Fixes Perl#22602
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Using signatures makes the debugger harder to use
4 participants