Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

debug/elf: cannot parse aarch64 relocations #8533

Closed
mwhudson opened this issue Aug 15, 2014 · 8 comments
Closed

debug/elf: cannot parse aarch64 relocations #8533

mwhudson opened this issue Aug 15, 2014 · 8 comments
Milestone

Comments

@mwhudson
Copy link
Contributor

What does 'go version' print?

go version devel +2cc71cd8fe3e Wed Aug 13 14:56:58 2014 -0700 linux/amd64

What steps reproduce the problem?
If possible, include a link to a program on play.golang.org.

1.  Find yourself an aarch64 elf file (for example, I have one here: 
2.  Feed it to this program: http://play.golang.org/p/jCO8h5Xlr5

What happened?

For me, I get bogus output that mostly consists of "long long int"

What should have happened instead?

It should list different names, something like:

long unsigned int
unsigned char
short unsigned int
unsigned int
signed char
short int
int
...

Please provide any additional information below.

The problem is that the relocations that update the debug_info section to have the
actual offsets into the debug_str are not being applied by debug/elf, because it has no
knowledge of the R_AARCH64_ABS32 and so on relocations that are used on that platform.

Of course, go doesn't run on aarch64 (yet) but I see that debug/elf knows about
relocations for powerpc, alpha and sparc, so that would appear not to be a constraint
against adding the aarch64 codes.

I ran into this trying to get cgo working on arm64 fwiw.
@minux
Copy link
Member

minux commented Aug 15, 2014

Comment 1:

I just fixed this for power64, see https://golang.org/cl/125910043/
Feel free to send CL. The worst case is that it will be deferred to 1.5,
but debug/elf isn't frozen, so I don't see any reason to delay (Plus we
do want arm64 port.)

Labels changed: added release-go1.4, repo-main.

Status changed to Accepted.

@mwhudson
Copy link
Contributor Author

Comment 2:

Ah awesome, that gives me a nice template to follow.  I'll try to send in a CL early
next week.

@mwhudson
Copy link
Contributor Author

Comment 3:

I wonder if .DWARF() should complain if there seem to be relocs for .debug_info that it
doesn't know how to handle?  I can't really imagine when this would be what you want
(maybe I'm just unimaginative?) and it would have saved me a good deal of hair pulling
:-)
(not going to get to a CL today)

@gopherbot
Copy link

Comment 4:

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

@ianlancetaylor
Copy link
Contributor

Comment 5:

In regards to comment #3: not all processor formats require doing any relocation on the
debug info.  In particular 386 does not when handling GCC-generated objects (I would
regard the fact that some versions of clang do require relocation as a bug).

@mwhudson
Copy link
Contributor Author

Comment 6:

Do those formats still have a .rel{,a}.debug_info section though?  It seems to me that
simply ignoring a relocation section is going to be more confusing than useful (it
certainly confused me!).  I'll change that section of my CL though, it's a distraction
from getting cgo to work...

@ianlancetaylor
Copy link
Contributor

Comment 7:

For purposes of debug/elf.DWARF, when using SHT_REL relocations, you can ignore all
relocations in .debug_info that are for section symbols of other .debug sections.  All
you need for those are the offsets, and for an SHT_REL relocation the offset will
already be in the debug info.

@ianlancetaylor
Copy link
Contributor

Comment 8:

This issue was closed by revision 299117e.

Status changed to Fixed.

@rsc rsc added this to the Go1.4 milestone Apr 14, 2015
@rsc rsc removed the release-go1.4 label Apr 14, 2015
@golang golang locked and limited conversation to collaborators Jun 25, 2016
wheatman pushed a commit to wheatman/go-akaros that referenced this issue Jun 25, 2018
This adds the minimal support for AArch64/arm64 relocations
needed to get cgo to work (when an isomorphic patch is applied
to gccgo) and a test.

This change uses the "AAarch64" name for the architecture rather
than the more widely accepted "arm64" because that's the name that
the relevant docs from ARM such as

   http://infocenter.arm.com/help/topic/com.arm.doc.ihi0056b/IHI0056B_aaelf64.pdf

all use.

Fixes golang#8533.

LGTM=iant
R=golang-codereviews, aram, gobot, iant, minux
CC=golang-codereviews
https://golang.org/cl/132000043
wheatman pushed a commit to wheatman/go-akaros that referenced this issue Jul 9, 2018
This adds the minimal support for AArch64/arm64 relocations
needed to get cgo to work (when an isomorphic patch is applied
to gccgo) and a test.

This change uses the "AAarch64" name for the architecture rather
than the more widely accepted "arm64" because that's the name that
the relevant docs from ARM such as

   http://infocenter.arm.com/help/topic/com.arm.doc.ihi0056b/IHI0056B_aaelf64.pdf

all use.

Fixes golang#8533.

LGTM=iant
R=golang-codereviews, aram, gobot, iant, minux
CC=golang-codereviews
https://golang.org/cl/132000043
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants