-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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
cmd/asm: referencing a variable from assembly in vendored package fails #28230
Comments
Am I understanding correctly that you are writing assembly code that refers to a variable defined in a different package? And then your code breaks if your packages are vendored in a different directory? As you've discovered, I don't think that is going to work. I don't really see any way that it could ever work. |
nop, the assembly code is referring variable in the same package. I'm asking myself 2 questions here:
Thanks for providing reference to the spec describing this behavior |
To refer to a variable in the same package, don't write out the package path. Just use a leading |
What if assembly code is referring to the variable from "internal" package? Is this allowed? |
I'm not sure what you mean by an "internal" package. In general I don't think it's going to work to have assembly code refer to a variable defined in a different package and to then try to vendor that package. |
I mean package in "internal" folder, but that's unrelated to this issue. In the spec I don't see why vendored package would be treated in a different way by the compiler than non-vendored, so my understanding is that this is a bug. But maybe there is something I don't see |
The spec doesn't discuss accessing variables in other packages from assembly code. It's not a feature of the language at all. Assembly code can access variables from the package that it is in, but there is no documented or supported way to access variables from other packages. It happens to work in some cases, and you've found a case where it doesn't work. Either way, it's not documented and not supported. I'm not opposed to changing something so that this works but I don't at present see how it could be done. |
Since there is no plan to do anything I'm going to close this issue. But please feel free to comment if you disagree. |
Ok, if it simply doesn't work, than fine, I coudln't care less. I just want to get clear statement. |
There simply isn't any supported way for assembly code to refer to a variable defined in a different package. |
yeah, I think that part was clear since beginning |
* Assembly code can't reffer to variables which are not in the same package. * utils/cpu.go keeps flags indicating CPU capabilities. Currently this file keeps flags specific to X86, those flags are set only if program is run on X86, hence on ARM they always be false. Flags are coppied to variables which are local to P503 and P751 (so that assembly code can access them). * we dont need workaround in utils/utils.go anymore as utils/cpu.go is never ignored by the buildtags. See also: golang/go#28230 Fixes #21
fix: fixes vendoring issue * Assembly code can't reffer to variables which are not in the same package. * utils/cpu.go keeps flags indicating CPU capabilities. Currently this file keeps flags specific to X86, those flags are set only if program is run on X86, hence on ARM they always be false. Flags are coppied to variables which are local to P503 and P751 (so that assembly code can access them). * we dont need workaround in utils/utils.go anymore as utils/cpu.go is never ignored by the buildtags. See also: golang/go#28230
Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (
go version
)?go version go1.10.4 linux/amd64
Does this issue reproduce with the latest release?
Well, not exactly. I still get an error but different
What operating system and processor architecture are you using (
go env
)?What did you do?
From assembly I reference a variable define in the same package. It works OK as long as package is not vendored. Best way to reproduce is to apply the patch below and run
The result is "70"
Now if I "vendor" the library "github.com/test/test":
I get an error:
What did you expect to see?
No difference in program behaviour between in vendored and non-vendored library
The text was updated successfully, but these errors were encountered: