This is an archive of the discontinued LLVM Phabricator instance.

[lldb] Fix broken bad-address-breakpoint test
ClosedPublic

Authored by hawkinsw on May 20 2022, 7:01 PM.

Details

Summary

After changing the "fallback" behavior when a user sets a breakpoint
without specifying a module the bad-address-breakpoint test case failed
incorrectly. This patch updates that test case in order to more
thoroughly discover an illegal address and use that as the means for
testing whether a breakpoint set at an illegal address fails to resolve.

Diff Detail

Event Timeline

hawkinsw created this revision.May 20 2022, 7:01 PM
Herald added a project: Restricted Project. · View Herald TranscriptMay 20 2022, 7:01 PM
hawkinsw requested review of this revision.May 20 2022, 7:01 PM
Herald added a project: Restricted Project. · View Herald TranscriptMay 20 2022, 7:01 PM
DavidSpickett added a subscriber: DavidSpickett.
DavidSpickett added inline comments.
lldb/test/API/functionalities/breakpoint/address_breakpoints/TestBadAddressBreakpoints.py
38

I'm confused as to what the logic is here now.

You:

  • read from address 0x0 to fill in error
  • walk the memory regions until the highest one, making the end of that the illegal address
  • assume that the error value from reading 0x0 is the same as you'd get from this new illegal address

...

Or am I missing something and the ptr was just left in accidentally.

(I would suggest you could jump to the last region in the list straight away but I don't think we actually require them to be sorted, plus sometimes you get multiple regions with the same base)

DavidSpickett added inline comments.May 23 2022, 1:41 AM
lldb/test/API/functionalities/breakpoint/address_breakpoints/TestBadAddressBreakpoints.py
38

(same base but different end addresses I mean)

hawkinsw added inline comments.May 23 2022, 10:49 AM
lldb/test/API/functionalities/breakpoint/address_breakpoints/TestBadAddressBreakpoints.py
38

Hello! Thank you for the review!

I was initializing illegal_address to 0 as a way to, well, initialize the value. I suppose that I could have initialized it to None and then used that a special value in the loop. In fact, now that I think about it, that's the tact that I will take in a second version of this patch.

But, yes, you basically have the rest correct: I walk through all the memory regions and find the highest address. Then, when I have that address (which I know is not in a valid memory region), I will use that as the address to set for the illegal breakpoint.

Does that make sense?

hawkinsw added inline comments.May 23 2022, 10:52 AM
lldb/test/API/functionalities/breakpoint/address_breakpoints/TestBadAddressBreakpoints.py
38

And, woah, I now realize what you meant! So sorry!

Yes, ptr was leftover. I am so sorry!

Standby for the next version of this patch!

hawkinsw updated this revision to Diff 431427.May 23 2022, 10:56 AM

Updating based on DavidSpickett helpful feedback.

@DavidSpickett Thank you for the review! I hope that this 2nd version of the patch addresses your helpful comments!

Will

DavidSpickett accepted this revision.May 24 2022, 3:00 AM

Much clearer now, thanks. LGTM with the one nit fixed.

lldb/test/API/functionalities/breakpoint/address_breakpoints/TestBadAddressBreakpoints.py
42

General rule is to use is None instead of == None, though the result is the same here.

This revision is now accepted and ready to land.May 24 2022, 3:00 AM

@DavidSpickett Thanks (again) for the feedback. Once I fix the nit, is the proper protocol for you to review again? I am sorry to ask but I don't know the right procedure and don't want to do the wrong thing!

lldb/test/API/functionalities/breakpoint/address_breakpoints/TestBadAddressBreakpoints.py
42

Yes! I always make that error!

@DavidSpickett Thanks (again) for the feedback. Once I fix the nit, is the proper protocol for you to review again? I am sorry to ask but I don't know the right procedure and don't want to do the wrong thing!

If the patch is accepted with a comment you can land the patch with the comment addressed. Unless you disagree in which case you can continue discussing in the code review.

hawkinsw updated this revision to Diff 432192.May 25 2022, 10:35 PM

Updating the revision to consider feedback (!= None vs is not None)

@DavidSpickett Thanks (again) for the feedback. Once I fix the nit, is the proper protocol for you to review again? I am sorry to ask but I don't know the right procedure and don't want to do the wrong thing!

If the patch is accepted with a comment you can land the patch with the comment addressed. Unless you disagree in which case you can continue discussing in the code review.

Thanks @JDevlieghere ! I have updated the patch according to his feedback and I am running a full test on my desktop. I think that this is ready to land but I still haven't gotten myself in order and requested committer access so I will need your help again.

Thanks again for your patience and help getting me acclimated! Contributing is lots of fun!

This revision was automatically updated to reflect the committed changes.