pcb: mark fields that should be preserved for kernel debuggers

[minsoochoo0122_proton.me]

Summary

Signed-off-by: Minsoo Choo <[e-mail]>

[kib]

My impression is that the whole pcb have to be considered part of the contract, unfortunately.
IMO instead of copying the amd64-style of the comment, it is better to remove the *-marking and make a herald comment describing that.

[minsoochoo0122_proton.me]

In D55149#1260992, @kib wrote:

My impression is that the whole pcb have to be considered part of the contract, unfortunately.
IMO instead of copying the amd64-style of the comment, it is better to remove the *-marking and make a herald comment describing that.

Why should we preserve the whole pcb structure? Are there programs depend on this other than kernel debuggers?

[kib]

In D55149#1261001, @minsoochoo0122_proton.me wrote:

In D55149#1260992, @kib wrote:

My impression is that the whole pcb have to be considered part of the contract, unfortunately.
IMO instead of copying the amd64-style of the comment, it is better to remove the *-marking and make a herald comment describing that.

Why should we preserve the whole pcb structure? Are there programs depend on this other than kernel debuggers?

I had to add and preserve the padding fields pcb_pad in the amd64 structure to be compatible with kgdb at least. This makes me sure that the whole pcb layout is fixed by ABI.

[minsoochoo0122_proton.me]

In D55149#1261002, @kib wrote:

In D55149#1261001, @minsoochoo0122_proton.me wrote:

In D55149#1260992, @kib wrote:

My impression is that the whole pcb have to be considered part of the contract, unfortunately.
IMO instead of copying the amd64-style of the comment, it is better to remove the *-marking and make a herald comment describing that.

Why should we preserve the whole pcb structure? Are there programs depend on this other than kernel debuggers?

I had to add and preserve the padding fields pcb_pad in the amd64 structure to be compatible with kgdb at least. This makes me sure that the whole pcb layout is fixed by ABI.

Sounds good to me. Since I'm not familiar with herald comment, could you write one for me?

[minsoochoo0122_proton.me]

update comment

[minsoochoo0122_proton.me]

update commit message

[kib]

sys/amd64/include/pcb.h

47–49

[minsoochoo0122_proton.me]

sys/amd64/include/pcb.h

47–49

Should I do the same for trapframes?

[kib]

sys/amd64/include/pcb.h

47–49

Are trapframes directly accessed by debuggers?

I am not surprised, but I plan to work on something that definitely changes trapframe on amd64. Most likely, it would only add some stuff at the end of the structure, and this 'something' is defined by hardware. But still, it is formally ABI breakage which is inevitable in this case.

[minsoochoo0122_proton.me]

sys/amd64/include/pcb.h

47–49

https://cgit.freebsd.org/ports/tree/devel/gdb/files/kgdb/amd64fbsd-kern.c:

Trapframe offsets are hardcoded like pcb offsets, so reordering will break the ABI. Adding extra field should be fine unless you want to add it to kgdb.

[kib]

sys/amd64/include/pcb.h

47–49

Then I suggest to talk about layout of existing fields in the comments, instead of the whole structure ABI.
I.e. the structure can be extended, but the layout (and semantic?) of existing fields must not change.

[minsoochoo0122_proton.me]

• frame.h: mark struct trapframe to be preserved

[kib]

sys/x86/include/frame.h

122 ↗

(On Diff #171381)

123 ↗

(On Diff #171381)

[minsoochoo0122_proton.me]

update comments

[kib]

sys/x86/include/frame.h

121 ↗

(On Diff #171387)

I suggest two drop the trapframe part of the change, and commit the pcb comment, it is fine with me as is.

After that, the trapframe part can be ironed in the separate review. I do not think it is correct to say about it that it must not be modified, because parts of it, at least on x86, are defined by hw. Unlike struct pcb, which is pure software construct.

[minsoochoo0122_proton.me]

remove frame.h