Refactor moduledata parsing using field offset tables (Issue #55)

[kami922]

Summary

This PR refactors moduledata parsing for Go versions 1.16-1.24 to eliminate repetitive version-specific switch statements by using a data-driven approach with field offset tables.

Problem

The current codebase has ~430 lines of duplicate code for parsing moduledata across different Go versions. Each version requires nearly identical parsing logic, making the code difficult to maintain and extend.

Before this PR:

• Go 1.16-1.24 moduledata parsing: ~430 lines of switch statements
• Adding Go 1.25 support: ~100 lines of duplicate code
• Maintenance burden: High (need to update all version cases consistently)

Solution

Implemented a generic field offset layout system that:

1. Defines field positions in data tables (not code)
2. Uses single generic parser for all versions
3. Separates data (layouts) from logic (parsing)

After this PR:

• Go 1.16-1.24 moduledata parsing: ~62 lines of generic code
• Adding Go 1.25 support: ~8 lines of layout data
• Maintenance burden: Low (changes isolated to data tables)

Code reduction: 85% (430 lines → 62 lines)

Changes

New Files

1. objfile/layouts.go (394 lines)

   • FieldInfo and ModuleDataLayout structs for defining binary layouts
   • Field offset tables for Go versions 1.16, 1.18, 1.20, 1.21-1.24
   • parseModuleDataGeneric() - version-agnostic parsing function
   • validateAndConvertModuleData() - validation for Go 1.18+
   • validateAndConvertModuleData_116() - validation for Go 1.16-1.17
   • Helper functions: readPointer(), readSlice(), getFieldOffset()

2. objfile/layouts_test.go (380 lines)

   • TestLayoutOffsets_Match_StructDefinitions - Verifies layout offsets match actual structs
   • TestParseModuleDataGeneric_BackwardCompatibility - Ensures identical output
   • TestVersionMapping - Tests version alias handling
   • TestReadPointer - Tests pointer reading with different endianness
   • TestReadSlice - Tests Go slice structure parsing
   • TestModuleDataIntermediate_FieldTypes - Verifies struct types

Modified Files

objfile/objfile.go

• Replaced lines 289-715 (~430 lines of version switches)
• Now uses generic parser with layout tables (~62 lines)
• Net reduction: 368 lines

Testing

✅ All tests passing

1. Unit Tests

   • Layout offset verification for all supported versions
   • Backward compatibility tests ensure identical output
   • Endianness handling (little-endian and big-endian)
   • Version mapping (1.22/1.23/1.24 → 1.21 layout)

2. Integration Testing

   • Tested against real Go 1.17.2 binary (testproject)
   • Output matches original implementation exactly
   • All existing objfile tests pass

3. Test Coverage

   $ go test ./objfile -v
   === RUN   TestLayoutOffsets_Match_StructDefinitions
   === RUN   TestLayoutOffsets_Match_StructDefinitions/ModuleData121_64
   === RUN   TestLayoutOffsets_Match_StructDefinitions/ModuleData121_32
   === RUN   TestLayoutOffsets_Match_StructDefinitions/ModuleData120_64
   === RUN   TestLayoutOffsets_Match_StructDefinitions/ModuleData118_64
   === RUN   TestLayoutOffsets_Match_StructDefinitions/ModuleData116_64
   --- PASS: TestLayoutOffsets_Match_StructDefinitions (0.00s)
   ...
   PASS
   ok      github.com/mandiant/GoReSym/objfile     0.094s
   

Extensibility
Adding Go 1.25 support:

• Before: Copy-paste ~100 lines, modify version numbers
• After: Add 8 lines of field offsets to layout table

Future Work

This refactoring establishes a pattern that can be extended to:

1. Older Go versions (1.2-1.15) - same approach
2. Type parsing (lines 1180-1700 in objfile.go) - similar switches
3. Other version-specific structures throughout the codebase

Estimated additional savings: ~500-600 more lines could be eliminated by applying this pattern to type parsing.

[kami922]

Hello I made a few mistakes while committing I had pushed commits to wrong branch earlier and then push wrong commits to this branch as well now i fixed it.

[stevemk14ebr]

This is good work! It passes all the tests and looks reasonable to me. Before merging I'd like if it could be extended to cover the additional cases in the objfile ModuleDataTable routine and the type parsing as you suggest.

For testing you can run the build_test_files.sh script which will use docker to generate many test binaries for different go runtime versions. Once those are generated you can run go test which will run GoReSym main_test.go against all versions and architectures of the generated test files.

[kami922]

@stevemk14ebr Hello and good day to you. I have ran build_test_files.sh for generating binaries 1.15-1.22 and ran go test and it passed all tests in my terminal

[stevemk14ebr]

Let's make the name and type an enumeration instead of strings. This should be a bit faster and add more structure

[stevemk14ebr]

The large switch on Interface runtime version in ParseType_impl could use for the same type of offset map to the methods list. We want to turn as many of these large version switches into offset maps as we can, most of the memory reading logic is already offset based rather than martialed for these cases.

case Interface:
		// type interfaceType struct {
		// 	rtype
		// 	pkgPath name      // import path (pointer)
		// 	methods []imethod // sorted by hash
		// }
		switch runtimeVersion {

[stevemk14ebr]

This looks great to me, thanks for cleaning this up! It passes all my unit tests as well as my manual testing.