This is an archive of the discontinued LLVM Phabricator instance.

[XCOFF] Decode the relocation entries of loader section of xcoff for llvm-readobj
ClosedPublic

Authored by DiggerLin on Oct 26 2022, 1:49 PM.

Diff Detail

Event Timeline

DiggerLin created this revision.Oct 26 2022, 1:49 PM
Herald added a project: Restricted Project. · View Herald TranscriptOct 26 2022, 1:49 PM
DiggerLin requested review of this revision.Oct 26 2022, 1:49 PM
Herald added a project: Restricted Project. · View Herald TranscriptOct 26 2022, 1:49 PM
DiggerLin updated this revision to Diff 476108.Nov 17 2022, 7:07 AM
jhenderson added inline comments.Nov 21 2022, 1:37 AM
llvm/include/llvm/Object/XCOFFObjectFile.h
253

I was just looking at the XCOFF loader section header spec, and it refers to a l_rdoff field, i.e. the offset of the relocation entries, but this struct here doesn't seem to define an equivalent field. Is this not supposed to represent the actual loader header struct in the file? It seems to me like it is intended to, due to the way the symbol table offset is calculated. (Admittedly, the description for this field contradicts the point of having the field, so I'm not entirely sure what to make of the spec).

llvm/tools/llvm-readobj/ObjDumper.h
158–159

Just spotted errors in this comment. See the Mach-O example below.

163

This field should be PrintRelocations because there can be more than one relocation.

llvm/tools/llvm-readobj/XCOFFDumper.cpp
44

Same as above (PrintRelocations). Also throughout the changes in this file.

286

It might be worth noting that this is a direct quote from the specification. Perhaps adding something like "From the XCOFF specification: there are five ...".

I'd be concerned putting in a detailed quote like this without any form of attribution.

311

Nit

312

This lambda is only used once. What's the motivation for it being a lambda, rather than putting the code directly inline?

325

Again, this lambda is only used once. What's preventing the code being directly written inline?

328–330

Please make sure to reflow again after making the suggested edits.

350

Prefer static_cast not C-style casts.

352

Typo. This appears in the output. Did you just copy the output of the tool to write your test? Be careful...

355

It would be worth factoring this "3" into a named constant in the function. Something like FirstSymbolIndex.

362

Nit: Don't end blocks with a blank line.

369

I'm not sure I follow why this and the if(Obj.is64Bit()) cases need distinguishing?

370

Use static_cast.

372
DiggerLin updated this revision to Diff 477583.Nov 23 2022, 1:08 PM
DiggerLin marked 13 inline comments as done.

address James's comment. thanks @jhenderson

DiggerLin marked an inline comment as done.Nov 23 2022, 1:09 PM
DiggerLin added inline comments.
llvm/include/llvm/Object/XCOFFObjectFile.h
253

there is document error on (Table 5. Loader Section Header Structure) https://www.ibm.com/docs/en/aix/7.2?topic=formats-xcoff-object-file-format#XCOFF__vra3i31ejbau . We have discuss internally. I implement based in the AIX OS /usr/include/loader.h (When in doubt, the header files should be believed.)

error as:

  1. in Table 5. Loader Section Header Structure

the field of l_rldoff (Offset to start of relocation entries) for 32 bits ,is

( -Offset: 36,
 -Length: 2)

but in the loader.h, it looks do not have the field and I used the llvm-objdump --full-contents libtest.a
to decode a 32bit example object file which has loader section . it also do not has the field l_rldoff (for 32bit xcoff object, the loader section head field has 32bytes when dump the data.)

  1. there is another error on offset of l_rldoff in 64bits

(-Offset: 64
-Length: 4).

the -Offset:64 should be -Offset: 48 , according to decode a loader section head of 64bits xcoff and loader.h

  1. (Table 7. Loader Section Relocation Table Entry Structure.) . According to AIX OS loader.h.

There should be no field "l_value" (Address field) in "Loader Section Relocation Table Entry" both XCOFF32 and XCOFF64.

  1. the Length of field "l_rtype" (Relocation type) should be 2 (not 4), and the Offset of "l_rtype" for 32bits should be "Offset:8".

the definiton for 32bit loader section header in the /usr/include/loader.h in AIX OS as

#ifdef __XCOFF32__

typedef struct ldhdr {
	_LONG32		l_version;	/* Loader section version number */
#define _CURRENT_LDR_VERSION	(1)
	_LONG32		l_nsyms;	/* Qty of loader Symbol table entries */
	_LONG32		l_nreloc;	/* Qty of loader relocation table
					   entries */
	_ULONG32	l_istlen;	/* Length of loader import file id
					   strings */
	_LONG32		l_nimpid;	/* Qty of loader import file ids. */
	_ULONG32	l_impoff;	/* Offset to start of loader import
					   file id strings */
	_ULONG32	l_stlen;	/* Length of loader string table */
	_ULONG32	l_stoff;	/* Offset to start of loader string
					   table */
} LDHDR;

#endif /* __XCOFF32__ */

#ifdef __XCOFF64__

typedef struct _S_(ldhdr) {
	_LONG32		l_version;	/* Loader section version number */

#ifdef __XCOFF32__
#define _CURRENT_LDR_VERSION_64	(2)
#else
#define _CURRENT_LDR_VERSION	(2)
#endif

	_LONG32		l_nsyms;	/* Qty of loader Symbol table entries */
	_LONG32		l_nreloc;	/* Qty of loader relocation table
					   entries */
	_ULONG32	l_istlen;	/* Length of loader import file id
					   strings */
	_LONG32		l_nimpid;	/* Qty of loader import file ids. */
	_ULONG32	l_stlen;	/* Length of loader string table */
	unsigned long long l_impoff;	/* Offset to start of loader import
					   file id strings */
	unsigned long long l_stoff;	/* Offset to start of loader string
					   table */
	unsigned long long l_symoff;	/* Offset to start of loader symbol
					   table */
	unsigned long long l_rldoff;	/* Offset to start of loader rlds */
} _S_(LDHDR);

#ifdef __XCOFF32__
#define	LDHDRSZ_64	sizeof(LDHDR_64)
#endif
llvm/tools/llvm-readobj/ObjDumper.h
163

I think whether to use "PrintSymbolTables" instead of "PrintSymbolTable" when I implement the decoding the symbol table of loader section. I think PrintSymbolTable can explain the we want to print symbol table out. (and we only one symbol table in the loader section, we have multi symbol table entries in the symbol table. ) the same reason for the PrintRelocation. if the parameter name is "PrintRelocationEntry", we should be change to "PrintRelocationEntries"

llvm/tools/llvm-readobj/XCOFFDumper.cpp
311

sorry about that

312

agree with you.

328–330

thanks

352

sorry, yes, But I used the patch to decode the relocations of the loader section of big lib which I copied from the /usr/lib and compare with the gnu objdump and compare the output , there has the same relocations result.

369

the fields order of relocation entry is different between 32bit and 64bit, I just keep the same order of the object file. not keeping the same order of the object file is OK for me. If you strong suggest me to not keep the order of object file. I can change it.

jhenderson added inline comments.Nov 25 2022, 12:58 AM
llvm/include/llvm/Object/XCOFFObjectFile.h
253

Thanks for the explanation, it makes sense. In the future though, I'd put such lengthy comments out-of-line, as they make it harder to follow the code!

llvm/tools/llvm-readobj/ObjDumper.h
163

Your analogy is flawed: "Relocation" and "SymbolTable" are not referring to the same kind of thing.

There is exactly one symbol table, hence why it is singular. The relocation entries consist of one or more relocations: "relocation entry" is just a verbose way of saying "relocation". The term for a group of relocations could be "relocation table" or "relocation section" (see ELF for good examples of this throughout). In other words, "relocation" is the same sort of thing as a "symbol". You could change the PrintSymbolTable parameter to PrintSymbols, but not to PrintSymbol for example.

llvm/tools/llvm-readobj/XCOFFDumper.cpp
334–336

As this expression is getting quite long, it might be worth splitting it into two or three local variables for ease of reading.

341

Test case for this warning?

369

FWIW, I don't think it's important to have the order match the data structure order, if there are reasons to do something else. In this case it will simplify code, and also people consuming this won't have to special case whatever scripts they write to handle the order being different.

DiggerLin marked 3 inline comments as done.
DiggerLin added inline comments.
llvm/tools/llvm-readobj/ObjDumper.h
163

thanks

llvm/tools/llvm-readobj/XCOFFDumper.cpp
341

I am not sure whether we need to test Symbol Name error in all different patch, we have the same test for the code
in https://github.com/llvm/llvm-project/blob/main/llvm/tools/llvm-readobj/XCOFFDumper.cpp#L234

jhenderson added inline comments.Nov 29 2022, 1:27 AM
llvm/tools/llvm-readobj/XCOFFDumper.cpp
341

This isn't about testing the internal generation of the error, this is about testing that the library-generated error is properly handled in the tool code (i.e. it's reported to stderr, and not thrown away, for example).

DiggerLin updated this revision to Diff 479299.Dec 1 2022, 8:06 AM

added a new test case to test invalid symbol name for relocation.

jhenderson accepted this revision.Dec 2 2022, 1:04 AM

Essentially looks reasonable to me, although I haven't verified that all the call paths are properly covered by tests. @Esme or another XCOFF developer should take a look at this before landing it.

FYI, my last day working before Christmas is next Friday, and I may have limited reviewing time next week. I won't be back and able to review things further after that until late January.

This revision is now accepted and ready to land.Dec 2 2022, 1:04 AM

Essentially looks reasonable to me, although I haven't verified that all the call paths are properly covered by tests. @Esme or another XCOFF developer should take a look at this before landing it.

FYI, my last day working before Christmas is next Friday, and I may have limited reviewing time next week. I won't be back and able to review things further after that until late January.

Thanks, James, have a good vacation. @jhenderson

Esme added a comment.EditedDec 7 2022, 2:31 AM

Feel sorry that i'm just getting started to review this patch.
I've applied the patch and test the functionality and it looks good overall. Thanks.
However, considering the printing format of relocations in llvm-readobj, when --expand-relocs is not specified, we usually print relocations in this format:

vaddr     section    type   symbol
20000294    2       POS   .data
2000029c    2       POS   0

Only when --expand-relocs is specified, we print relocations like the format in this patch.
The --dyn-relocations option also follows such rule.

@jhenderson What do you think?

llvm/include/llvm/Object/XCOFFObjectFile.h
243

I noticed an extra field of l_value for Loader Section Relocation Table Entry Structure specified by the doc, is it also a doc error?

Esme added a comment.Dec 7 2022, 2:35 AM

Btw. Do you have any plans to implement an option like "--loader-section" to embrace all this loader section related information?

Btw. Do you have any plans to implement an option like "--loader-section" to embrace all this loader section related information?

Yes, after I have a plan to implement the option "--loader-section" and I also have plan to reimplement of "[llvm-readobj][XCOFF] Add support for --needed-libs option." which will print the needed-libs in the "loader sections"

DiggerLin updated this revision to Diff 481086.Dec 7 2022, 3:27 PM
DiggerLin marked an inline comment as done.

added a new no expand relocation format.

Esme added a comment.Dec 7 2022, 6:55 PM
llvm/tools/llvm-readobj/XCOFFDumper.cpp
318–320

Prefer to move the code (lines 315~317) into the else code block below (line 353).

319

We seem to be more accustomed to abbreviating Section as Sec, is it more meaningful to change RelSect to SecNum?

365–366
DiggerLin updated this revision to Diff 481393.Dec 8 2022, 1:07 PM
DiggerLin marked 2 inline comments as done.

added decode size of relocation type in --expand-relocs

Some nits, but the idea of implementing expand relocs behaviour here seems reasonable to me. This will likely be my last post on this review until I'm back at the end of January. Feel free to not wait any further on me.

llvm/tools/llvm-readobj/XCOFFDumper.cpp
319

I would actually here print "Section" or "SectionIndex". Ultimately though, do the same as we do for ELF, I recommend.

320

Text intended to be read by humans should have spaces between words...

350

Perhaps worth putting the ExpandRelocs behaviour into a small helper function (not a lambda), just to avoid making this function too long.

359–361

Word wrapping has gone weird here.

DiggerLin marked 5 inline comments as done.Dec 9 2022, 7:43 AM

Btw. Do you have any plans to implement an option like "--loader-section" to embrace all this loader section related information?

llvm/include/llvm/Object/XCOFFObjectFile.h
243

yes, this is doc error. I have mention it in comment which I response to James.

llvm/tools/llvm-readobj/XCOFFDumper.cpp
318–320

if move the lines into "else code block below (line 353)." , it is in the loop , it will cause the "Vaddr Type SecNum SymbolName(Index)" be printed multi time. (this is only head line.)

319

thanks

319

in AIX doc , it always use SectionNumber, and all implement of llvm tools, it always use SectionNumber. not Section Index.

DiggerLin updated this revision to Diff 481655.Dec 9 2022, 7:56 AM
DiggerLin marked an inline comment as done.
Esme added a comment.Dec 11 2022, 9:37 PM
This comment was removed by Esme.
Esme accepted this revision.Dec 11 2022, 9:37 PM

LGTM. Thanks!

This revision was landed with ongoing or failed builds.Dec 14 2022, 8:16 AM
This revision was automatically updated to reflect the committed changes.
jhenderson added inline comments.Jan 30 2023, 2:21 AM
llvm/tools/llvm-readobj/XCOFFDumper.cpp
321–322

Nit: this word wrapping wasn't fixed when the code was moved. Please make an NFC commit (no review needed) to fix it.