binfmt: Add a configuration flag to store the module filename

[jlaitine]

Summary

This flag can be used to store the filename of a loaded module or executable in binfmt. The filename is useful for example in debugging. For debugging purpose, gdb or a jtag debugger can be configured to automatically fetch the symbols for the currently executing module.

I have been using this to help in debugging applications in CONFIG_BUILD_KERNEL, autoloading symbols whenever the target is stopped with gdb.

I don't know if there are existing or better ways to achieve the same, if there is a better way or more complete "OS awareness" available for gdb, we can just ignore this.

I am only offering the method here, in case others find it useful as well.

Here is an example script of how such feature can be utilized using gdb:
smp_autosymbols.py

Usage in gdb:
set $cpu_index = 0 # for smp, set cpu index for each gdb server
set $symbol_path_prefix = "<path_to_symbol_elf_files>"
source /<path_to_script>/smp_autosymbols.py

Impact

No impact on any existing configurations, just adds the executable name in bin in case the flag is defined in .config.

Testing

Tested in IMX9 platform, CONFIG_BUILD_KERNEL, SEGGER JLink + GDB.

[xiaoxiang781216]

@jlaitine how about tcb_s::name which contain filename pass from binfmt's exec_module by nxtask_init

[jlaitine]

@jlaitine how about tcb_s::name which contain filename pass from binfmt's exec_module by nxtask_init

This is a bit difficult; tcb_s::name is just a name of the task. When the module creates threads, the name of these threads doesn't indicate the process binary name. In this case, one would need to first find the group pid, then calculate the pid hash to the kernel's hash table, go search the group leader's tcb in hash table and finally check the name from there. But every executing thread already has a pointer to the bin, so this was an easy place to store the binary filename...

[acassis]

@jlaitine although there is already other places in the code that checks for filename size, I suggest using NAME_MAX instead of sizeof(bin->fname) to reduce the chance someone inject a buffer overflow by populating fname with a big string

[jlaitine]

sizeof(bin->fname) evaluates at compile time to the defined size of the fname vector, i.e. NAME_MAX in this case. Using sizeof here just avoids defining the size in two places, that is, if size of the fname is changed in the struct, there is no need to change it also in here.

Having said that, I can change it in here if you like it better!

[xiaoxiang781216]

sizeof is better than NAME_MAX since it automatically match the new length if someone change definition later.

[xiaoxiang781216]

should we enable it always or reuse CONFIG_TASK_NAME_SIZE?

[linguini1]

Tested in IMX9 platform, CONFIG_BUILD_KERNEL, SEGGER JLink + GDB.

Can you please show the test logs/test scenario?

[xiaoxiang781216]

Tested in IMX9 platform, CONFIG_BUILD_KERNEL, SEGGER JLink + GDB.

Can you please show the test logs

not all change generate the different output, why do you enforce the contributor provide a visible log?

/test scenario?

the description already contain:

Usage in gdb:
set $cpu_index = 0 # for smp, set cpu index for each gdb server
set $symbol_path_prefix = "<path_to_symbol_elf_files>"
source /<path_to_script>/smp_autosymbols.py

[jlaitine]

Tested in IMX9 platform, CONFIG_BUILD_KERNEL, SEGGER JLink + GDB.

Can you please show the test logs/test scenario?

Sorry but this doesn't produce any logs as such. My only case is to use this is to help identifying the binary module file while debugging. If this feature would be used for something else, then logs would be appropriate of course!

[linguini1]

not all change generate the different output, why do you enforce the contributor provide a visible log?

It's not about looking for a change in the logs, it's looking for logs that prove there was a build/test to prevent regression (i.e. looking for no change in logs)

It is hardly enforcing, I asked politely if the author could provide some logs. This is a requirement by NuttX, which we all voted on.

The author gave justification about why logs aren't necessary here, and I agree with them. So I will not block the PR or anything.