Cfi update#138
Conversation
Converted the clarification updates from 003-clarification-cfi.txt into markdown. Then merged them with the parts from 013-generalize-address-spaces.md that were left out of the address space proposal. Then merged inHeavy editing of CFI updates the new operator from 017-call-frame-entry-registers.txt into one pro posal that handles alConverted the clarification updates from 003-clarification-cfi.txt l the CFI loosinto markdown. Then merged them with the parts from e ends. Began addi013-generalize-address-spaces.md that were left out of the address ng something like the operation headers tspace proposal. Then merged in the new operator from o the CFA Instru017-call-frame-entry-registers.txt into one proposal that handles all ctions. the CFI loose ends. Began adding something like the operation headers to the CFA Instructions. Signed-off-by: Ben Woodard <woodard@redhat.com>
Signed-off-by: Ben Woodard <woodard@redhat.com>
More work on the CFI proposal. Still WIP. Signed-off-by: Ben Woodard <woodard@redhat.com>
New intro -- much better. Kind of brings the whole topic together. Begin adding prototype like headers to rules. Signed-off-by: Ben Woodard <woodard@redhat.com>
markus-metzger
left a comment
markus-metzger
left a comment
There was a problem hiding this comment.
I stopped reviewing at some point. I think this needs the high-level design described in the introduction.
Going through the changes, I suspect that the intent is to turn CFA into a location and make all CFI rules yield locations. I'm not convinced that this is strictly necessary. It seems to add complications and turns simple and clear rules into something rather complicated.
Defining CFA as an integral offset in some ABI-defined address-space (which could be some generic address-space covering multiple address-spaces) would leave most of CFI intact. I would like to see an example where this simpler approach would not work.
| > *Previously, the Call Frame Location, CFL, was known as the Call | ||
| > Frame Address, CFA. However, GPUs do not necessarily store | ||
| > previous frames on the stack, they may pushed to some local | ||
| > storage in the GPU. So it is not quite to appropriate to assume |
There was a problem hiding this comment.
Wouldn't that 'local storage in the GPU' also behave like a stack? Are we just talking about different address-spaces or something more exotic?
|
|
||
| With: | ||
|
|
||
| > An area of memory that is allocated on a stack called a “call |
There was a problem hiding this comment.
I'm not convinced that CFA needs to be a location and cannot be an integral offset in an ABI-defined address-space that contains the stack.
| with "Call Frame Location" in the paragraph that describes what the | ||
| CFL is. | ||
|
|
||
| > The previous value of this register is the undefined location |
There was a problem hiding this comment.
It is not clear where this is to be added. Looks like it is replacing the 'undefined' rule. I think it is fine as it is unless we want to change all CFI register rules to produce a location. The introduction did not say anything like that (or I didn't find or understand it).
| requirements that are different than CPUs. In particular, they have | ||
| multiple address spaces and and can spill registers to them. Some | ||
| architectures of GPUs can even spill registers to other registers | ||
| which are farther away in their memory hierarchy. The fact that GPUs |
There was a problem hiding this comment.
What does 'farther away in their memory hierarchy' mean in the context of registers?
| multiple address spaces and and can spill registers to them. Some | ||
| architectures of GPUs can even spill registers to other registers | ||
| which are farther away in their memory hierarchy. The fact that GPUs | ||
| use various locations to store previous frames which cannot be |
There was a problem hiding this comment.
What does 'use various locations to store previous frames' mean? Can we give a concrete real-world example?
| following: | ||
|
|
||
| > The previous value of this register is located either in a generic | ||
| > value or in implicit storage produced by evaluating the DWARF |
There was a problem hiding this comment.
If the producer wanted to use implicit storage, why did it not use the 'expression(E)' rule?
I see no issue with restricting 'val_expression(E)' to values that can be pushed onto the stack and leave the rule to define the value of the register as the top stack element after evaluating E.
Another big chunk of edits as I pound this into shape. Several of the edits needed discussion by the group and needed to be resolved there. Thanks to Markus Metzger for his review comments. Several of them have been taken care of but several still need to be worked through and resolved. Signed-off-by: Ben Woodard <woodard@redhat.com>
2 participants
Heavy editing of CFI updates
Merged all the proposals which deal with CFI back into one bigger proposal.