I need to add a explanation of malloc types

• Wordsmith

Remove password prompt from the example

• address feedback (I answered some of the comments directly or at least marked them as done)
• sort copyright header

I have been testing this again recently, and it works fine, at least with the tests I ran. I think we should go ahead and get it into the tree, it's been sitting in review for 3 years almost. releng/15.0 is branched so there is no fear of breaking the release, even though this shouldn't break anything in the first place, it's a kinst-specific change and at worst it won't always yield 100% correct results. Once we have it in tree we can work on remaining issues, but I do not see a point in keeping it here anymore.

In D39259#1136450, @markj wrote:

I think this is subsumed by commit 5bd7b976c1214cd6357b74f491753a331f9b7c99.

• UMA -> uma

Closed via 9388c2887817d7162ebb356b39aa9b4ab67a8c00.

Thanks, Mark!

• Add the enum to the definition

Great! Thanks for explaining, Mark :)

Please don't commit this. It's not necessary, and you're just hard-coding internal values from the kernel. The fplookup result status number is just an implementation detail and isn't part of any stable interface.

In D51315#1172217, @0mp wrote:

In D51315#1172185, @markj wrote:

Another side note: wouldn't it be nice to create a vfs.d in /usr/lib/dtrace so that we could use the actual enum for arg2 instead of integers? The enum would be:

Just change the type from int to enum cache_fpl_status in the probe definition, and it'll work. dtrace knows about enum names since they're encoded in CTF info.

ah, so the actual fix should be:

SDT_PROBE_DEFINE3(vfs, fplookup, lookup, done, "struct nameidata *", "enum cache_fpl_status", "bool");

do I understand correctly?

I'm not sure if that would work. DTrace seems to not know about the the constants like CACHE_FPL_STATUS_DESTROYED at all. How would the type change fix that? I'll try that later. Maybe DTrace does some magic that makes it work.

Alternatively, I've opened another revision that adds the enum to libdtrace/vfs.d, but I suspect that this is not the right fix based on Mark's last comment.

In D51315#1172185, @markj wrote:

Another side note: wouldn't it be nice to create a vfs.d in /usr/lib/dtrace so that we could use the actual enum for arg2 instead of integers? The enum would be:

Just change the type from int to enum cache_fpl_status in the probe definition, and it'll work. dtrace knows about enum names since they're encoded in CTF info.

Another side note: wouldn't it be nice to create a vfs.d in /usr/lib/dtrace so that we could use the actual enum for arg2 instead of integers? The enum would be:

We can of course fix them later, but I did send a mail asking about how we write the synopsis. These SYNOPSIS(es?) do introduce bugs in apropos results.

• Pet mdoc linters

• Address Christos' feedback

Thanks!

• Capitalize descriptions of aggregation functions

@ziaee, could you check the apropos(1) compliance? ;)

• Address feedback

I haven't checked mandoc -Tlint, but make sure there are no errors there as well.

Thanks!

• Address feedback

• Address bcr's comments

• Add bcr's comments

• Apply bcr's comments

• Fix a typo in Example 1

• Fix ERROR's args (arg0 should not be documented; real arguments are arg1-arg5)
• Expand example 2

• Document execargs
• Add a note what execname is.

• Move cwd to BUGS and mention that it is not supported at the moment.

• Address bcr's feedback
• Reference ddb(4) as the kernel debugger, not kgdb

• Use SPDX

Finish the first draft.

A few minor things, the rest looks fine.

• Improve Nd

In D51188#1168819, @zldrobit_gmail.com wrote:

@markj I found that we should also delete st_value = 0 in dt_module_symsort32/64(), otherwise dmp->dm_aslen would always be lesser than dmp->dm_asrsv by at least one. As a result, dt_module_symsort32/64() ignore the last element in dmp->dm_asmap and dt_module_symaddr32/64() wouldn't find it. I had to update the patch accordingly. Sorry for interrupting the test suite procedure.

In D51188#1168819, @zldrobit_gmail.com wrote:

@markj I found that we should also delete st_value = 0 in dt_module_symsort32/64(), otherwise dmp->dm_aslen would always be lesser than dmp->dm_asrsv by at least one. As a result, dt_module_symsort32/64() ignore the last element in dmp->dm_asmap and dt_module_symaddr32/64() wouldn't find it. I had to update the patch accordingly. Sorry for interrupting the test suite procedure.

@markj I found that we should also delete st_value = 0 in dt_module_symsort32/64(), otherwise dmp->dm_aslen would always be lesser than dmp->dm_asrsv by at least one. As a result, dt_module_symsort32/64() ignore the last element in dmp->dm_asmap and dt_module_symaddr32/64() wouldn't find it. I had to update the patch accordingly. Sorry for interrupting the test suite procedure.

I'll commit this once I've gone through the test suite.

@avg Sure, I recreated the patch with the -U999 option.

The patch is updated:

1. Delete sym->st_value != 0 in dt_module_syminit32().
2. Generate patch file with -U999 option.

This change looks reasonable to me. I think the problem with st_value = 0 only applies to ET_REL KLDs.

@zldrobit_gmail.com if you cannot submit the change for review from Git (e.g., using git-arc), can you update it with a diff created with -U999 option?

Bump.

In D38825#1144242, @christos wrote:

In D38825#1136408, @markj wrote:

I will spend some time testing this again within a week. My recollection from last time is that there were some edge cases where probes didn't fire when I expected. One thing I didn't test yet but am a bit suspicious will not work properly is stack unwinding -- did you test that the stack() action prints reasonable output when used within an inline function probe?

I will test it in the following days.

In D38825#1136408, @markj wrote:

I will spend some time testing this again within a week. My recollection from last time is that there were some edge cases where probes didn't fire when I expected. One thing I didn't test yet but am a bit suspicious will not work properly is stack unwinding -- did you test that the stack() action prints reasonable output when used within an inline function probe?

I think this is subsumed by commit 5bd7b976c1214cd6357b74f491753a331f9b7c99.

I will spend some time testing this again within a week. My recollection from last time is that there were some edge cases where probes didn't fire when I expected. One thing I didn't test yet but am a bit suspicious will not work properly is stack unwinding -- did you test that the stack() action prints reasonable output when used within an inline function probe?

After some testing, this generally works fine for me. As per our chat on IRC, one thing I'd quite like before this lands are two additional tests in dtrace_test, one for a simple tail call and one for tail recursion which is unrolled into a loop (both should be achievable via __attribute__((musttail)), though I'm not 100% clear on how to ensure that you get the desired loop unrolling behaviour for recursion. See https://clang.llvm.org/docs/AttributeReference.html#musttail for more details). Even if they don't necessarily pass, I think it's OK to land this and simply fix the tail calls later as the state of things with this change would still improve over what's currently there.

tinderbox build on the cluster done with no errors.

The "Inline Function Tracing" section in the following paper I wrote for AsiaBSDCon 2024 gives an overview of what this patch does: https://papers.freebsd.org/2024/asiabsdcon/margiolis-Arbitrary-Instruction-Tracing-with-DTrace.files/asiabsdcon2024-margiolis-arbitrary-instruction-tracing-paper.pdf

• Remove unncessary goto.
• Rebase on top of main.