Add GOFF read/write support

[dalvescb]

This PR adds read and write support for GOFF

Read Support

• Sections: GOFF Element Definitions (ED) and Section Definitions (SD) are mapped to sections
• Symbols: A subset of symbol types are exposed in ObjectSymbolTable (LD, PR, ER), this matches what we are doing in our LLVM tooling
• Non-contiguous data: Since section/segment data is split across non-contiguous TXT records, data() returns an error directing users to uncompressed_data(), which assembles the complete section data from all contributing records.
• Symbol Names: GOFF uses EBCDIC encoding and supports long names via continuation records. To avoid ASCII/EBCDIC conversions and lifetime issues with non-contiguous data, name() returns an error in favor of name_parts(), which returns a vec of raw byte slices that can be assembled by the caller.
• Relocations: RLD (Relocation Directory) records are parsed and exposed as relocations with full R-pointer/P-pointer information preserved in RelocationFlags::Goff. Generic RelocationKind mapping is best-effort based on relocation flags.

Write Support

• Complete write implementation supporting sections, symbols, relocations, and all GOFF record types (HDR, ESD, TXT, RLD, LEN, END).
• Expects raw bytes for EBCDIC-encoded symbol names (no conversion provided)

Testing

• Round-trip tests in tests/round_trip/goff.rs verify write/read consistency for sections, symbols, and basic relocations.
• Relocation tests in tests/round_trip/goff_relocation.rs verify relocation parsing and reconstruction.
• I have read tests with sample object files and objdump output, but are not included in this PR. I'll open a separate PR in testfiles to add those first

Note: you can refer to the spec here IBM z/OS GOFF Specification

[philipc]

Thanks for the PR. I probably won't get to review this for a few days or more. You may have noticed I moved the GOFF support to an unstable feature in #962. My plan is to do an object release first, and then get this merged and do any followup work. Once that is done, we can remove the unstable requirement for GOFF and if it didn't require any breaking changes in the non-GOFF code then we can do a patch release.

However, if there is anywhere that you think it would be beneficial to have a breaking change in the non-GOFF code in order to accommodate GOFF then now is the time to do it. I didn't notice anything from a quick look through this PR. name_parts is currently only on GoffSymbol, and it may be beneficial to add that to ObjectSymbol too, but that won't be a breaking change.

It would be useful to have the fixtures in testfiles before I review this so that I can try running on some real files.

[dalvescb]

Thanks for your consideration

My plan is to do an object release first, and then get this merged and do any followup work. Once that is done, we can remove the unstable requirement for GOFF and if it didn't require any breaking changes in the non-GOFF code then we can do a patch release.

Sounds good, I'll make sure to update this PR to reflect any changes that are made if necessary inbetween this and the next release

However, if there is anywhere that you think it would be beneficial to have a breaking change in the non-GOFF code in order to accommodate GOFF then now is the time to do it.

Noted, I don't believe we'll require any breaking changes to satisfy our needs. I don't see any issue with leaving name_parts as a GoffSymbol only method for our purposes.

It would be useful to have the fixtures in testfiles before I review this so that I can try running on some real files.

I've opened a PR to add sample testfiles here gimli-rs/object-testfiles#45 . If that lands ahead of time, I'll update this PR to bump the submodule and add my read tests

[philipc]

Some comments from a quick read through, I haven't looked at anything in detail yet.

Also, there doesn't appear to be any testing of continuation records, either here or in the object-testfiles additions.

GOFF is still new and foreign to me, so please push back if I make any suggestions that don't make sense to you.

[philipc]

I think this is good to merge after a submodule update.

I find it easier to become familiar with the code by actually working on it, so I plan to do some followup work myself (in particular implement support in the readobj example), and I'll fix things I notice while doing that.

[dalvescb]

I think this is good to merge after a submodule update.

Great, submodule has been bumped to main

I find it easier to become familiar with the code by actually working on it, so I plan to do some followup work myself (in particular implement support in the readobj example), and I'll fix things I notice while doing that.

Feel free to ping me whenever if you need some clarification / have GOFF specific questions. Sorry about my previous delayed response, I just came back from vacation