Overall LGTM. I'd prefer we keep the uses in macho_file.rb the way they are, but the #to_s implementations themselves look good!

Ah, that makes sense. I just reverted that file to its original state.

LGTM. Could you add a few small tests for the new #to_s impls? Putting them in the same test blocks as the methods they wrap is fine.

I was able to add to the tests in the test_create_load_commands.rb file for the DyLibCommand and RpathCommand classes. Most of the other LoadCommand classes don't really seem to have tests yet as far as I can see so I don't really know where to add those tests.

When I added an assert to the test_macho.rb file related to the SegmentCommand class it brought up a few more linter errors which I solved by changing the style and excluding one of the cops from the test folder. These linter errors only showed up on the pre-commit checks not when running the tests beforehand which was weird.

Never mind I now see that run-tests doesn't actually run the linter so those warnings were always there. I think that it still might be a good idea to exclude that cop from the tests folder either way.

It spits out the following warning type three times.

test/test_macho.rb:150:11: W: Lint/AmbiguousBlockAssociation: 
Parenthesize the param MachO::Sections::SECTION_ATTRIBUTES.keys.any? { |sa| sect.attribute?(sa) } 
to make sure that the block will be associated with the MachO::Sections::SECTION_ATTRIBUTES.keys.any? method call.
          assert MachO::Sections::SECTION_ATTRIBUTES.keys.any? { |sa| sect.attribute?(sa) }

I'm gonna go over to the Rubocop repo and see what they have to say about it.

Edit: I think I understand what the cop is saying now. They want the asserts to look like this. I've made that change so now that warning shouldn't show up for those three lines in the test_mach.rb file.

assert(MachO::Sections::SECTION_ATTRIBUTES.keys.any? { |sa| sect.attribute?(sa) })

LGTM, thanks.