Dyno: add backtracing LLDB script

[DanilaFe]

LLDB exposes a convenient Python API. We can leverage this API to print clean stacktaces while resolving Dyno programs. See also my comment in the file.

Dyno stack trace script.

Though Dyno often performs re-computation, it's typical for the
compiler stacktrace to mirror (with a lot of function calls) the trace of
resolving the Chapel program. We can clean up this information, skipping
a lot of in-between frames, and print a Chapel-only trace. That's what this
script does.

To use the script, add the following lines to your .lldbinit file:

    command script import /path/to/dyno_backtrace.py
    command script add -f dyno_backtrace.backtrace dbt

Then, in the debugger, you can run the `dbt` command to print the Chapel
stack trace.

The output looks like this:

(lldb) dbt
 0: chpl__buildDomainRuntimeType at input.chpl:3 (lldb frame 152)
 1: init at /modules/internal/ChapelDomain.chpl:110 (lldb frame 137)
 2: newAssociativeDom at /modules/internal/ChapelDomain.chpl:1117 (lldb frame 118)
 3: dsiNewAssociativeDom at /modules/internal/ChapelDistribution.chpl:115 (lldb frame 103)
 4: init at /modules/internal/DefaultRectangular.chpl:110 (lldb frame 88)
 5: init at /modules/internal/DefaultAssociative.chpl:96 (lldb frame 69)
 6: init= at /modules/internal/ChapelHashtable.chpl:260 (lldb frame 45)
 7: chpl__promotionType at /modules/internal/OwnedObject.chpl:40 (lldb frame 27)
 8: borrow at /modules/internal/OwnedObject.chpl:49 (lldb frame 13)

Reviewed by @arifthpe -- thanks!

[arifthpe]

Lgtm, but I'm not familiar with the LLDB api so it's a pretty basic review.

Why not add this to compiler/etc/lldb.commands and have it loaded in chpl --lldb by default?

[DanilaFe]

it would be of limited utility in chpl --lldb (since, without --dyno, it doesn't use the dyno resolver), but I see no harm in adding it.

[DanilaFe]

Actually, because I am not sure how this will work when the switch is thrown outside of the "usual" developer environment (e.g., what if a homebrew install throws --lldb?), I'd rather not mess with the commands file.

[Copilot]

Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.

Comments suppressed due to low confidence (1)

util/devel/dyno_backtrace.py:50

• [nitpick] Using magic indices for accessing frame variables (e.g., index 0, 1, and 3) makes the code less clear; consider introducing descriptive variable names or constants to document the expected variable roles.

rc = frame.variables[0]

[Copilot]

The function get_child_by_name assumes that a child with the specified name exists, which may result in a StopIteration error if not found. Consider adding error handling or a default value.

Suggested change

	def get_child_by_name(value, name):
	return next(child for child in value.children if child.name == name)
	def get_child_by_name(value, name, default=None):
	try:
	return next(child for child in value.children if child.name == name)
	except StopIteration:
	if default is not None:
	return default
	raise ValueError(f"Child with name '{name}' not found")