FAIL: os_test.TestLongSymlink on XFS #62
Labels
Comments
|
Owner changed to [email protected]. Status changed to Started. |
|
This issue was closed by revision f07a9e4. Status changed to Fixed. Merged into issue #-. |
minux
added a commit
to minux/goios
that referenced
this issue
Feb 27, 2015
Updates golang#62. We still need to figure out why MOV $"".p+CONST, R3 uses constant pool at all when CONST is directly encodable.
minux
pushed a commit
to minux/goios
that referenced
this issue
Feb 27, 2015
This change fixes a lot of related bugs. ARM64 is a 64-bit machine, and the most general constants are 64-bit. The most general constant class was C_LCON, which is 32-bit. We change it to C_VCON. This didn't affect much because there weren't many assumptions on the size of C_LCON, but it allows us to use C_LCON for quantities which we know are 32-bit and could use a more efficient encoding (none so far). This change also makes the distinction between memory addresses (C_ADDR, which require relocation) and other 64-bit constants (C_VCON). Optab instruction variants for C_VCON quantities were duplicated to also work on C_ADDR where it makes sense. We could have simply made C_VCON equal C_ADDR in cmp, so existing instruction forms would have worked, but this way we can distinguish between instructions that need to operate on relocatable addresses and instructions that can operate on generic 64-bit constants, providing more theoretical safety. This change also enables more immediate forms, requiring less pool literals. Some forms still don't work, however, but most do. Another side effect of this change is fixing linking. Because we didn't use optimal immediate encodings, we generated more constant types that we originally accounted for. The extra constants were catched by a default switch case, which assumed they were all relocations, and issued relocations for them. The linker then complained it couldn't find the referenced symbols. Updates golang#6 Fixes golang#62
This issue was closed.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
by dan.hovang:
I'm trying to build the compiler (the plan9-based one) on Linux with XFS file system. This is what happens: gopack grc _test/os.a _gotest_.8 make[2]: Leaving directory `/store/home/dan/install/go/src/pkg/os' --- FAIL: os_test.TestLongSymlink symlink "0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef", "longsymlinktestfrom" failed: symlink 0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef longsymlinktestfrom: file name too long FAIL make[1]: *** [test] Error 1 make[1]: Leaving directory `/store/home/dan/install/go/src/pkg/os' make: *** [os.test] Error 2 My setup is: GOARCH=386 GOOS=linux changeset: 3975:b51fd2d6c160 tag: tip user: Kevin Ballard <kevin at sb.org> date: Tue Nov 10 20:05:24 2009 -0800 summary: Implement new emacs command M-x gofmt It seems like the test is creating a 273 character symlink. XFS support only 255 character file names. Strange thing is, according to Wikipedia, ext3 has the same 255 character limitation. Maybe ext3 just silently truncate the filename? The whole thing builds just fine on a ReiserFS partition on the same machine (which supports 4 032 character file name).The text was updated successfully, but these errors were encountered: