Amend commit message

Fix indent

Use Makefile.crates

Elaborate commit message and manual

Sorry I cannot find other use case. Do you have any idea on the use case of raw tcp? Due to the unsafeness of raw TCP. We should use this feature in localhost. And because of the lack of terminal command in raw TCP support. It is much better to use modem device rather than raw tcp in localhost. So this feature actually is for proxy only (like OpenStack) because most of these applications implement raw tcp connection rather than modem device. But if we support telnet it will be useful because it is much simpler than modem device on configuration. I am planning to do so but we need this feature first because telnet is built upon tcp.

Hello, is there any update about this? Anyone want to merge this can use this to have direct patch.

Use ::1 for safe ipv6 address

User 127.0.0.1 instead of 0.0.0.0 in manual

For the 0.0.0.0 problem. I think we should fix it in the separated patch as we should also modify the VNC part.
Here is the branch that follows up the upstream modification of this patch:

Elaborate manual over TCP raw socket

Thanks for your feedback and here is the patch

Use warn instead of warnx on system call

Fix some typo and double close

Rebase and refactor comment

Prevent race condition in is_socket

• Add bhyve uart tcp backend
• Add manual page

• Add bhyve uart tcp backend
• Add manual page

@imp Hello, I found this needed feature in your idea list. Do you have any problem or feedback?

Fix it

Comply with space style

Add extra id for smbus

Remove useless newline

Move SCALE outside

Bump gstat manual

Reduce double outside scale

Apply clang-format

Rebase to main and make scale more obvious

Backward competible implementation

So do you means we only aware of the incompatible kernel and don't implement similar check for kernel module?

I think you are right, I don't think about kernel problem. And in my opinion, it is the chicken-and-egg conundrum if we implemented it in a normal ELF way (rely on VMA of section) for kernel. But it is still a mitigation for driver developer when developing kernel module. Besides, we still need uuid_addr for relocatable kernel module. I have extract my patch to contain relocatable file handling only. So I think we should preserve this patch not merge it until finding a way to verify who is the correct kernel? (by extended the kernel dump header as you mentioned or something else?)

Expose uuid for kernel module in kernel to prevent incompetable coredump loaded by debugger for relocatable file

But we cannot just rely on the file to tell use where the memory is because it maybe wrong after you compile the module. For relocatable file, you don't even have VMA to tell you where is the memory. We should use uuid_addr from kernel memory. This is why I think we should have build-id feature (The file loaded is different from the one statically resides in your file system)

Got it. Thanks for your response!

Just a question, how you test on kernel, I use spike --kernel /path/to/kernel /path/to/sbi. It give me invalid address error even after I add -m0x1000000,0x2000.

Update to 2024-05-31

So should we divided our patch into amd64/arm64 for further discussion about two cases. Or divided the patch into kernel/loader?

• Add bhyve uart tcp backend
• Add manual page

• Add bhyve uart tcp backend
• Add manual page

• Add bhyve uart tcp backend
• Add manual page

• Add bhyve uart tcp backend
• Add manual page

Fix it!!

• Add bhyve uart tcp backend
• Add manual page

• Add bhyve uart tcp backend
• Add manual page

I fix the previous error previously mentioned, and because uart_tcp_disconnect is a helper function and it parent has already lock it. I add comment to let everyone use this function in the future know this.

• Add bhyve uart tcp backend
• Add manual page

Reset commit because I use wrong ID

• Add bhyve uart tcp backend
• Add manual page

Sorry about my late reply. The patch Ed commit is the pre-request to ensure my patch work. The logic of my patch is the loader would load the build-id from elf file in .gnu.note.build-id section into memory. When kernel crashed, it generate coredump and the build-id loaded from the loader will dump into the coredump file at the same time. After that, when debugger load kernel and it's coredump, the debugger will try to find the elf file of module and its debug file. We can compare the build-id from memory with elf file. If they are different, we shouldn't load the debug file (because they are incompatible).

LLDB refer build-id as UUID. Sorry about the imprecise word.

After my investigation, I discover that shstrtab section is not loaded into memory (because no SHF_ALLOC). Thus I cannot compare the section name with ".note.gnu.build-id". Besides, in link_elf_link_preload, the function don't open the file as link_elf_load_file but use all of the memory and preload information from boot1. Thus if I want to compare the section name, I should load the file, create temp memory space for it, and read file. Does it worth to a file in kernel just for compare a section name?

I understand your point, I will try not to modify the loader.

Seperate to two patches

For preloaded relocatable kernel module, I think the modification of loader is necessary as I discover SHT_NOTE section was not loaded by boot1 originally when the kernel module is preloaded.
For shared object, actually we can get the address of uuid when kernel is loaded. I modify the loader because I discover that CTORS pass the information from loader and I think I should follow it?

In D45161#1030112, @kib wrote:

It probably makes sense to split the change into two: one for loader, one for kernel.

Don't we need to ensure that notes are preserved, in the modules linker scripts? (sys/conf/ldscript.kmod.ARCH)

I assume that the debugger changes as well as adding UUIDS to the built modules would happen somewhere else?

• Add uuid for module to prevent incompetable coredump loaded by debugger
• Expose offset of uuid_addr and uuid_size in linker_file for debugger

Abandon because I submit the new one.

Fix it!

Check the result of calloc

Sorry I falsely create a duplicate patch...

I think MarkJ is right and then we can abandon this patch and just let the LLDB guys merge the patch into LLDB.

I will ask you again in AsiaBSDCon personally because I found something strange on my experiment. Thanks your guys help!

Does it works? Because the section name can only appear once in a ldscript. So if we move the .note.gnu.build-id section into rodata, it will cause the ELF cannot find this section and finally PT_NOTE segment will not contains .note.gnu.build-id. Besides, without this section, we cannot get the build-id hash data from section VMA as the most debugger expected.

Tidy up commit