Are you asking why doesn't it execv(2) addr2line deep within the libc malloc implementation? Because calling execv(2) within libraries is frowned upon.. ;-)
The leak report is being generated internally by malloc. It is then logged via utrace(2) when a process is traced through ktrace(1).
The kdump utility simply dumps the report, strvis(3) escaping any potentially unsafe characters. As this is untrusted user data, passing it as the input/args to another command is unwise. Also kdump(1) uses pledge(2) and cannot execute commands.
I guess I’m confused what’s printing the output here. On other OSes typically things like this are implemented by malloc recording the addresses and whatever parses the report later doing the symbolication when displaying it. I guess kdump just dumps the report but is there no porcelain that takes the kdump data and cleans it up a bit more for human consumption?
You are arguing for a worse UX because of an arbitrary reason. Just link against the code in addr2line. Providing a good UX should always be in scope for a project.
The leak report is being generated internally by malloc. It is then logged via utrace(2) when a process is traced through ktrace(1).
The kdump utility simply dumps the report, strvis(3) escaping any potentially unsafe characters. As this is untrusted user data, passing it as the input/args to another command is unwise. Also kdump(1) uses pledge(2) and cannot execute commands.