There's a lot of other linker-related overlap, some of which is only now becoming clear to me.

For example, cmd/internal/obj.LSym and cmd/link/internal/ld.LSym. I believe if obj.LSym had an Extra interface{} field that cmd/link could use, then we could replace most of ld.LSym. Given I did some recent cleanup of ld.LSym, I'll attempt to do the same to obj.LSym and see how close I can get to merging those types.

The code in goobj is meant to be able to be used by cmd/objdump to enable
objdump of .o files. I think that never made it into objdump, but it still
should, so please don't delete the code. I guess if I hadn't deleted
cmd/newlink there would be a test. :-(

The new format is just about replacing the ar framing with zip framing. The
goobj-parsed part current called a .o file will still exist, just inside
the zip archive.

On Fri, Mar 11, 2016 at 4:22 PM Matthew Dempsky notifications@github.com
wrote:

In CL 20489, @crawshaw https://github.com/crawshaw observed that he was
able to change the cmd/internal/obj's objfile writing code and
cmd/link/internal/ld's objfile reading code, but no tests failed to
indicate that cmd/internal/goobj should be updated too.

cmd/internal/goobj used to be used by cmd/newlink, but that was deleted in
CL 20380 (fb880b8
fb880b8
).

It's also still used in cmd/internal/objfile/goobj.go, but that file isn't
otherwise used either.

I imagine that because of #14386
#14386, we might as well just remove
the dead code.

/cc @rsc https://github.com/rsc

—
Reply to this email directly or view it on GitHub
#14782.

In that case I think we should plan on eventually deleting the objfile reading code cmd/link/internal/ld/objfile.go, and using goobj instead in cmd/link.

Please do NOT merge cmd/internal/obj and cmd/internal/ld. The first is
about writing object files and the second is about reading them. The
point of splitting the code was so that they could diverge reasonably, so
that the reading-specific parts could be dropped from one and the
writing-specific parts dropped from the other. They can both get cleaner
that way. I would like to get back to the point where cmd/link does not
import cmd/internal/obj at all. It didn't used to, but there was some
well-intentioned and reasonable cleanup that undid that separation this a
while back in order to avoid some duplicated constant definitions. It would
be good to split those constants out into a separate shared package
(cmd/internal/objfile maybe) and then add a test to go/build that cmd/link
cannot depend on cmd/internal/obj.

On Fri, Mar 11, 2016 at 4:26 PM David Crawshaw notifications@github.com
wrote:

There's a lot of other linker-related overlap, some of which is only now
becoming clear to me.

For example, cmd/internal/obj.LSym and cmd/link/internal/ld.LSym. I
believe if obj.LSym had an Extra interface{} field that cmd/link could
use, then we could replace most of ld.LSym. Given I did some recent cleanup
of ld.LSym, I'll attempt to do the same to obj.LSym and see how close I can
get to merging those types.

—
Reply to this email directly or view it on GitHub
#14782 (comment).

+1 on moving the shared constants and file format documentation into a separate package that both cmd/internal/obj and cmd/link can use.

Also, apparently I'm mistaken. The cmd/internal/goobj code is linked into nm, objdump, etc. It looks like it should be at least manually testable by running "go tool nm" on a compiled Go .o file. We just don't seem to have tests for that functionality though.

I think I was still a bit confused when I wrote that. What I'm interested in is merging the two pieces of objfile reading code we have: cmd/internal/goobj/read.go and cmd/link/internal/ld/objfile.go.

That would mean some kind of type sharing between cmd/internal/goobj.Sym and cmd/link/internal/ld.LSym.

It looks like ld.LSym could have goobj.Sym as a field inside it, and use the goobj reading code.

I looked at that a bit a few months back. The problem I ran into is that ld.Reloc has several more fields than goobj.Reloc but goobj.Sym has a slice of goobj.Relocs... I guess it's not that many really, so they could be added, but Xadd/Xsym don't really "belong" in goobj. The other thing is that goobj's struct have SymID's everywhere where ld has *LSyms, which IIRC ends up conflicting with the idea of using a symbol table in object files.

CL https://golang.org/cl/20104 mentions this issue.

CL https://golang.org/cl/37797 mentions this issue.

I think we can consider this fixed by CL 42971, which adds a test that exercises the code (and which was written in response to a surprise goobj failure). Feel free to reopen if you disagree.