How to debug some module?

[microsoft]

How to debug some module?

[vladimir-cheverdyuk-altium]

Thank you for such detailed explanation!

Because I'm not familiar with code I was trying to see how BuildXL works by putting breakpoints on different places and run HelloWorld example. And as a result, I usually have to do few iterations like this:

• add Debugger.Launch()
• build via bxl.cmd
• run ...\Out\Bin\Debug\win-x64 /c:config.dsc in HelloWorld directory
• Attach debugger to see if this was right place
• Sometimes switching to second copy to browse thru code
• Remove Debugger.Launch()

This constant switching is killing me and I was secretly hoping that there is better way :) Like setup external program and parameters, put breakpoint and press F5 in VS. Then I actually tried it and it works! Last time I was too concentrating on forcing VS to build that project that I actually never tried it.

And because I almost never change code, it works for me. And I can run it manually or setup Post-Build event to run bxl.cmd -minimal.

Thank you very much for you help!

Vlad

[marcelolynch]

Hello Vlad,

Unfortunately our VS integration is not optimal -- the easiest way to debug is to set the BuildXLDebugOnStart environment variable to 1. This will launch the debugger at the beginning of BuildXL's execution, so you don't have to add the Launch() line yourself. While debugging your own changes you should build BuildXL with bxl [-minimal] -deploy Dev and then execute using bxl -use Dev. This will ensure the correct symbols are loaded so VS will hit all your breakpoints.

To debug while running a test adding the explicit Debugger.Launch() line at the beginning of the test is best, because the tests will run in a separate process so the whole environment variable thing described above won't work.

[vladimir-cheverdyuk-altium]

Thank you for your answer. I tried this way and it didn't work nicely. If I use BuildXLDebugOnStart then breakpoint in other modules would not hit.

I tried to use Debugger.Launch() and it works better because bxl.exe is stay running for some time and I can put breakpoint later or earlier in execution stages.

But in both cases I cannot do code navigation. Only navigation in current module is working and if class is from different module then Ctrl+Click does not work. Most classes have quite nice and helpful description that helps understanding. But because Ctrl+Click does not work, I cannot see it. As result I have to keep 2 instances of Visual Studio, one for debug and one for browsing code and experience quite code.

If I may ask, what approach/tools are you using to debug and develop BuildXL?

Vlad

[marcelolynch]

May I ask how you are building the project? Are you building the VS solution with bxl -vs? Does code navigation work when you are not debugging?

We use Visual Studio and debug the way I described. While building the solution (using bxl -vs) you shouldn't apply any filters or run with -minimal or you may hit some of the issues you're describing with code navigation.

Additionally, note that BuildXL sometimes runs in a "server mode" to save some time in successive executions: this leaves a running bxl.exe process after executing (this may not be causing any issues for you but sometimes it can interfere when you are making changes and want to rerun a new version of your changes). You can run in single-instance mode by killing this surviving process (there's also a killbxl.cmd in the repo root that does this) and running with the /server- argument.

[vladimir-cheverdyuk-altium]

I ran bxl -vs only once because I don't do any changes to code except putting Debugger.Launch(). Code navigation works without any problems.

I'm building project using bxl.cmd -minimal.

Just to double check, it is not possible to build anything from VS and VS is only for code navigation, right?

[marcelolynch]

Building from VS (using F5) should work in theory, although to be honest I never use it :(

My usual workflow for debugging my changes is

1. Build my changes with bxl.cmd -minimal -Deploy dev. This will build and deploy the binaries to Out\Selfhost\Dev
2. set BuildXLDebugOnStart=1
3. Run a build with my newly built binaries, either with bxl.cmd -minimal -Use dev (this will execute the script using the Out\Selfhost\Dev binaries) or using Out\Selfhost\Dev\bxl.exe directly. As long as you don't -deploy Dev again these binaries won't change.

For launching the debugger in a test, it suffices to add the Debugger.Launch() to the test and then run the test with bxl.cmd -TestMethod [FullyQualifiedTestMethodName] [NameOfModule].dsc. No -Deploy dev needed here.

For example for the ConcurrentBigMapTests.TestConcurrentBigMapOperations test in BuildXL.Utilities.Collections.dsc I would run:

bxl.cmd -TestMethod Test.BuildXL.Utilities.ConcurrentBigMapTests.TestConcurrentBigMapOperations Test.BuildXL.Utilities.dsc

You can also test the whole class like this:

bxl.cmd -TestClass Test.BuildXL.Utilities.ConcurrentBigMapTests Test.BuildXL.Utilities.dsc

I hope this helps.