redstar wrote:
> Does this make sense or am I missing something here?
I think that splitting the SD/ED/LD into 3 "section"s implies that a
MCSectionGOFF has a fundamentally different semantic than the other
MCSectionXXX. This is something I would like to avoid. On the other hand, the
SD/ED pair is almost the same as an ELF section, so just putting those 2 into a
MCSectionGOFF instance and handling the LD/PR symbol differently makes sense.
In HLASM, a section definition looks like
```
HLASMHEL CSECT * The SD symbol
HLASMHEL AMODE 64
HLASMHEL RMODE ANY
C_CODE64 CATTR EXECUTABLE,RENT * The ED symbol; the LD symbol is
automatically generated.
ENTRY MAIN
MAIN AMODE 64
MAIN XATTR LINKAGE(XPLINK),SCOPE(LIBRARY),REFERENCE(CODE)
MAIN DS 0FD * A "normal" label, with attributes.
Results in another LD symbol
```
When I switch sections, and later want to continue the code section, then I
need to repeat both statements in a short form:
```
HLASMHEL CSECT ,
C_CODE64 CATTR ,
```
I thought about this when moving the definitions from the SymbolMapper to the
MCObjectFileInfo class, but I got no good idea how to handle the LD or PR
symbol. A possible way could be to attach the LD or PR symbol as the begin
symbol of a section. I need to try this.
One possible downside is that it makes handling of relocations much more
complicated. For the base of a relocation, I need the PR symbol (when I have
the SD/ED/PR case) or the LD and ED (in the SD/ED/LD case). Currently, this
information is available in the MCSectionGOFF, without the need to chase a list
to the correct element.
https://github.com/llvm/llvm-project/pull/133799
_______________________________________________
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
