This patch implements parsing sections for obj2yaml on AIX.
Better to add brief comment like length or symbol table index, depending on symbol type.? Like D68650.
As I see this test is not auto-generated? So can we reduce the indents to make the diff minimal?
Why not change return type to Error?
Put break inside brace.
You'll need someone with XCOFF experience to review this too. Generally looks fine from my brief look though.
It would be nice if we could replace the canned binary input with a YAML input and then use yaml2obj to produce the YAML for consumption by obj2yaml at some point in the future. That'll allow us proper flexibility to test all code paths.
Nit: add extra spaces to make things line up nicely.
Should this be a CHECK-NEXT though? If so, delete the blank line above it.
Perhaps report this as a regular error using createStringError()? No need for report_fatal_error when we have an easy way to report the Error after all.
No need for the else here.
This and the similar relocation check below - do you actually need it? If a user had an invalid object, where the section type was different to what it should be (e.g. a bug in an object producer), this check would prevent using obj2yaml, yet in my mind, the YAML could easily represent this state.
Yes, I agree with that. However, the yaml2obj is not yet fully implemented and some fields this test need like the symbol auxiliary entries are not yet supported in yaml2obj. I will replace the canned binary input with a YAML input in the future.
There is no particular reason for obj2yaml support to be ahead of yaml2obj, except that if I can use obj2yaml to convert compiled object files to readable yaml files, it will help me to implement yaml2obj.
The problem is that there's currently quite a lot of noise (e.g. the excessive section content) in this test that isn't all that useful. There are also a number of cases that aren't properly covered by this test input (e.g. sections with no relocations, empty sections etc), and you may find it difficult to cover all of them using a canned binary. Better to wait until you've got sufficient yaml2obj support for the basic structure, and then develop the two in tandem (i.e. add a feature to yaml2obj and at the same time, mirror it in obj2yaml).
There's of course nothing stopping you having this patch applied locally to help you in your yaml2obj development.
Here and throughout, you need testing for your error cases, i.e. what obj2yaml does when this error is triggered.
Do you have testing for the case where this is false?
I'm not convinced this belongs at all. Why do you do this check only for debug builds?
Here and elsewhere - this is the more normal TODO syntax in LLVM.
You still need testing for your error cases, i.e. showing that obj2yaml produces a suitable error (or possibly follows some fallback path) when it encounters invalid content.
Here and below, we usually remove excessive spacing, so that the values neatly line up, as close as possible to the tags. See the suggested edit for an example of what I mean.
Probably, this should just be errc::not_implemented (or something along those lines) - the file type is valid, we just haven't added support yet.
Is there much difference between 64 and 32-bit sections though, or could you just remove this error entirely and do the right thing?
Strictly, this should be like the inline edit (and same immediately below), but I'm not too fussed by that.
|1 ↗||(On Diff #371779)|
You should consider splitting this test into separate files, e.g. invalid-section and invalid-symbol, as I suspect it will grow as obj2yaml support for XCOFF improves.
|13–20 ↗||(On Diff #371779)|
|28 ↗||(On Diff #371779)|
Not for this patch, but it would be nice if we could get the actual useful error message, rather than the error code converted to an error message. That would ensure the message actually provides useful context (here the question could be raised "which section index? Where was it and what was its value?"
This error path appears to be untested?