Add in the ability of parsing symbol table for 64 bit object.
Is this error user-facing (I'm assuming so)? Assuming it is, you should record here which symbol is causing the problem. Otherwise the user will be faced with an error along the lines of this:
error: this csec symbol contains no auxiliary entry
which is not really actionable (imagine the input had 100000 symbols in - the user can't realistically go through each to find the offending one).
Similar to my above comment - which entry was not found? Give the user more context so that they can act on the problem.
This will write the error inline, rather than to stderr. Are you sure that's what you want? it isn't what most dumping tools do on failure.
I believe this requires std::move(Error);, as you're returning an Expected, not an Error.
I think it would make more sense to insert the name in the middle of the message to make it a bit more concise. Something like:
I'd suggest quoting somehow the symbol name, so that any whitespace or similar that happens to end up in the name (rare, but possible to write using assembly, at least for other platforms) is easily understood to be part of the name.
Use reportError or reportWarning so that the error is reported in a clean manner and consistent with other llvm-readobj varieties, and not report_fatal_error which looks like a crash. General rule of thumb: try to avoid using report_fatal_error, especially in tool code where it is easy to report errors properly.
In llvm-readobj for ELF, we try to avoid even using reportError where possible, as that stops the tool from continuing dumping, which can be problematic occasionally. We prefer reportWarning (or more specifically the local reportUniqueWarning which avoids reporting the same warning multiple times) and bailing out of the current routine. Take a look at ELFDumper.cpp for examples.
reportUniqueWarning can take an Error directly, so you can just do:
if (!ErrOrCsectAuxRef) reportUniqueWarning(ErrOrCsectAuxRef.takeError());
Also, be careful, as the program continues, so referencing ErrOrCsectAuxRef after this may result in things going wrong...
Only some minor nits, otherwise LGTM. I haven't attempted to review the test coverage for all the new code, as I don't feel like I'm in a good position to do that, not being an XCOFF developer. I assume someone else has though.
Basically any time you use consumeError, add a comment explaining why it's justified that we don't report the error to the user.
this is only for the 32bits .
for 64bit, it maybe look for the x_auxtype ==AUX_CSECT
if (AuxEntPtr->AuxType != XCOFF::AUX_FILE ) , it should not be parsed as
if (AuxEntPtr->AuxType != XCOFF::AUX_CSECT) , it should not be parsed as
I think it's the caller's responsibility to make sure they are passing in the right auxiliary type. So we should assume when we enter this function, we have the right auxiliary type here. So I modified it and made it an assert instead.
Same above. I modified it to be an assertion instead.
Good point. Updated the code.
SymbolAuxType is only for the 64 bits.
as you mention "I think it's the caller's responsibility to make sure they are passing in the right auxiliary type. "
I think we need to check the AuxType == XCOFF::AUX_FILE for 64 bits. if not , print out the raw data as AUX_CSECT did ?
we have iterated auxiliary entries from line 382~396 and reiterated again in the printCsectAuxEnt(). I think we can improve on it.
And in 64bits, The auxiliary entries maybe be reordered in above implement.
I don't think we reiterated again in printCsectAuxEnt() for other auxiliary entries.
I took a quick look at the pre-merge output. The message is that the object isn't recognised as a valid object file, not that it wasn't found, which suggests either the object or code is broken in some manner, or you're missing a dependent patch. Does this patch depend on another patch that isn't in main yet?
i -> I
(you're changing most of the loop body - you might as well fix this whilst you're here)
My English language ping went off at the word "till" in these two sentences. I'd probably change it to "to". Also, use "first" rather than "1st", I suggest in both places.
Also "skips" -> "skip" for grammatical consistency.
i -> I
I added an newline after all the raw bytes. Other than that, I think the output is good. We have 18 bytes per symbol table entry, and we are printing 18 raw bytes here.
I don't know if it is, but you probably want 00fb indented to line up nicely with the previous line. You can then confirm that this indentation is maintained by enabling --match-full-lines and --strict-whitespace in FileCheck. (If you do that, you'll need to remove the space after CHECK-NEXT:)
Hi James, I adjusted the code to print 00fb in the same line, I think that actually works better because we could have multiply auxiliary entry data to print out. Putting each in the same line is easier to parse.