[PATCH] D66969: Output XCOFF object text section header and symbol entry for program code
Digger via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Tue Oct 1 08:47:02 PDT 2019
DiggerLin marked 7 inline comments as done.
DiggerLin added inline comments.
================
Comment at: llvm/lib/MC/XCOFFObjectWriter.cpp:391
+ // table entries for a detailed description. Bits 0-3 is for symbol
+ // visibility. Bit 10 (0x0020) can be set if the symbol is a function in the
+ // old XCOFF32 interpretation. Otherwise bit 10 should be 0. Since we don't
----------------
hubert.reinterpretcast wrote:
> DiggerLin wrote:
> > hubert.reinterpretcast wrote:
> > > Use the shorter version of the comment here too,
> > changed as suggestion
> There are some cases here of two consecutive spaces. It is not necessarily wrong, but we should be consistent.
delete extras space.
================
Comment at: llvm/lib/MC/XCOFFObjectWriter.cpp:298
+ Asm.writeSectionData(W.OS, Csect.MCCsect, Layout);
+
+}
----------------
hubert.reinterpretcast wrote:
> We have code that introduces alignment padding, so I suspect we should have code here to write out the padding.
Added new function to support it.
================
Comment at: llvm/lib/MC/XCOFFObjectWriter.cpp:525
BSS.Index = SectionIndex++;
- assert(alignTo(Address, DefaultSectionAlign) == Address &&
- "Improperly aligned address for section.");
- uint32_t StartAddress = Address;
+ BSS.Address = Address;
for (auto &Csect : BSSCsects) {
----------------
hubert.reinterpretcast wrote:
> A comment is necessary here regarding alignment padding between the start of the section and the first item allocated within the section (which might require a stricter alignment). A question is why such padding is done "physically" in within the section as opposed to doing the padding "virtually" by adjusting the section's address in the address space.
added a comment
================
Comment at: llvm/test/CodeGen/PowerPC/aix-xcoff-common.ll:84
; SYMS-NEXT: Symbol {
-; SYMS-NEXT: Index: [[#Index:]]
-; SYMS-NEXT: Name: a
+; SYMS: Index: [[#Index:]]{{[[:space:]].*}}Name: a
; SYMS-NEXT: Value (RelocatableAddress): 0x0
----------------
hubert.reinterpretcast wrote:
> I think this warrants more explanation. Is the ability of the regex to match non-space characters intended?
there is Index: 0
Name: .text
before Symbol {
Index: 2
Name: a
origin test case will match .text symbol first and the value of Index will be zero.
using ; SYMS: Index: [[#Index:]]{{[[:space:]].*}}Name: a
can make sure that it match Symbol {
Index: 2
Name: a
not symbol .text and the index value will 2.
Repository:
rL LLVM
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D66969/new/
https://reviews.llvm.org/D66969
More information about the llvm-commits
mailing list