Initial support for GOFF

[dalvescb]

As a first step for adding support for s390x-ibm-zos (see rust-lang/compiler-team#992), I'd like to add support for GOFF, z/OS's native object format. To get started, I've added some basic definitions to represent GOFF records and a goff feature.

I'll have a number of non-trivial PR's to follow up this one. GOFF uses a non-contiguous record-oriented format, unlike the contiguous byte streams used by other object formats in this crate. So not everything in the current API is going to map onto cleanly. I'd appreciate any feedback the maintainers can give to make this as painless as possible

[philipc]

Can you explain a bit about what your implementation plan is? How much have you already implemented? How do we support the non-contiguous record-oriented format?

[dalvescb]

Can you explain a bit about what your implementation plan is? How much have you already implemented? How do we support the non-contiguous record-oriented format?

To expand a bit further, I have enough of a working implementation to satisfy the compiler frontend. Writing isn't much of an issue, and for reading most of the API is implementable if I stitch together records after parsing. This isn't too messy and shouldn't be much of a performance concern, however some of your current API expects data returned with a 'data lifetime. Since I have to allocate new memory to return a contiguous slice, it's not possible to maintain the lifetime constraint. This means either I'll have to leave those methods unimplemented, and provide ad-hoc goff methods to accomplish the same effect, or we'll need to adjust the lifetime constraints.

As an example the ObjectSection::data() method expected to return a slice &'data [u8]. This method will not be implementable with the current lifetime (not without leaking memory). Would you consider changing the lifetime to 'file?

Thanks for giving this your consideration, this may be more clear if I give you another PR with my implementation and those methods currently left unimplemented so we can discuss further? Just let me know how you prefer to continue

[philipc]

As an example the ObjectSection::data() method expected to return a slice &'data [u8]. This method will not be implementable with the current lifetime (not without leaking memory).

This is also a problem for OMF (#807), and we've currently got it returning an error for this case.

[philipc]

Thanks!

[philipc]

Since you've implemented enough to satisfy the compiler frontend, I'm happy to merge PRs as you see fit, and we can see what API changes are needed at the end.