Add AIX support in gimli symbolizer

[bzEq]

No description provided.

[ecnelises]

Do we need to upgrade object to 0.31.0 and enable xcoff feature? (there's one upgrading it #522 )

[workingjubilee]

That's weird. More of the tests should be not-failing at this point. Can you rebase this on master? The object bump is merged, for note.

[bzEq]

Rebased and fixed build failures.

[workingjubilee]

Thanks for the rebase! Is there a version of cargo that can build this while cross-compiling? With -Zbuild-std, perhaps?

This review is not exhaustive! Rather, having appropriate connections drawn would make it much easier to properly review and, most importantly, maintain, so later updates to this crate don't accidentally burn down all your hard work.

[workingjubilee]

Is this standing in for c_char? I would prefer the type was annotated appropriately, if so. I don't really care about other "ctypes", but c_char is special in C so I prefer to be pedantic about that particular one.

[bzEq]

The prototype of loadquery in C is

int loadquery(int Flags, void *Buffer, unsigned BufferLength);

Usually, we allocate a char * buffer in C and pass it to loadquery.
Are you implying we should modify the type in libc crate?

[workingjubilee]

Oh.
It should probably have been *mut c_void in the libc bindings, then.
You know that the libc crate's stability policy means that you effectively cannot change the bindings in the libc crate, right? It does breaking changes only very, very rarely, and considers virtually everything to be breaking if it could possibly at all be breaking. So you should probably avoid committing unnecessary platform-specific bindings to it.

[workingjubilee]

Also I realized my initial review includes a lot of specific questions about segments in the code and what the supporting concepts are for explaining them, but you don't need to address all of those questions in such a point-by-point manner if you want to take a more high-level approach to documenting (or pointing to existing documentation of) the concepts in question.

[bzEq]

you don't need to address all of those questions in such a point-by-point manner if you want to take a more high-level approach to documenting (or pointing to existing documentation of) the concepts in question.

I'll try my best to give an overview of AIX ABI. Since the latest AIX ABI is not formally documented, its behaviors largely depend on assembler manual and current implementation of IBM OpenXL/XL.

[workingjubilee]

Ah, I had a feeling it might be something like that. That unfortunately motivates my questions more, since we can't easily look up things and instead have to piece together answers from the scraps we can dig up. But I'm somewhat familiar with typical Power ISA assembly, at least, so this assembler manual is very helpful.

[bzEq]

Gentle ping.

[workingjubilee]

Took a new look. Thank you for addressing the prior round of review, having scanned the documentation a bit I feel relatively confident we can land this once a few last questions and cleanups are done.

[workingjubilee]

I would prefer this consistently uses if-else-if nesting or consistently use "rely on earlier break/return" instead of this crossing-over between the two styles. My understanding of this control flow is each of these expressions can only be reached if all conditions before them fail to be met, just like in an if-else-if-else chain, so there is no need for the early return to have its own if-statement, unless the entire set is "flat".

I do realize they are conceptually separate but that also means the break; doesn't need an else after it.

[workingjubilee]

Okay, my question re: why the control flow is like this also becomes: is there a reason this unwraps instead of using something like

Suggested change

	if Error::last_os_error().raw_os_error().unwrap() != libc::ENOMEM {
	return Vec::new();
	}
	buffer.resize(buffer.len() * 2, mem::zeroed::<libc::ld_info>());
	match Error::last_os_error().raw_os_error() {
	Some(libc::ENOMEM) => buffer.resize(buffer.len() * 2, mem::zeroed::<libc::ld_info>()),
	Some(libc::EINVAL | libc::EFAULT) => /* something? */,
	_ => unreachable!(),
	}

When reasoning by negation and positive reasoning are equally available, I prefer to avoid negation.

[workingjubilee]

Same remarks regarding eliminating rightward drift as earlier.

[workingjubilee]

Also feel free to squash/rebase this with your next pass of changes to however the commit history should look.

[bzEq]

Addressed comment and rebased. Thanks @workingjubilee for great suggestions on coding style.

[github-actions]

Below is the size of a hello-world Rust program linked with libstd with backtrace.

Original binary size: 533920B
Updated binary size: 530744B
Difference: -3176B (-0.59%)

[bzEq]

Gentle ping.

[workingjubilee]

Excellent, thank you!