Hi Ivan,
I think there is no problem to build latest gollvm in docker container now.
There is no need to add "-fcf-protection" explicitly to CFLAGS/ASM_FLAGS
any more according recent patches.
On Wednesday, July 29, 2020 at 12:10:35 PM UTC+8, Ivan Serdyuk wrote:
>
> Yuan,
> do you have any progr
Yuan,
do you have any progress here?
Ivan
On Thursday, May 28, 2020 at 6:47:41 AM UTC+3 Yuan Ting wrote:
> Thanks for your correction, overriding CMAKE_C_FLAGS and CMAKE_ASM_FLAGS
> with "-fcf-protection=none" works for me.
> I also try to build gollvm from a clean slate (by recreating a build
Thanks for your correction, overriding CMAKE_C_FLAGS and CMAKE_ASM_FLAGS
with "-fcf-protection=none" works for me.
I also try to build gollvm from a clean slate (by recreating a build area
and rerun cmake without overriding CMAKE_C_FLAGS and CMAKE_ASM_FLAGS).
However, I still failed to build gol
>> I can successfully compile and link gollvm by setting
CMAKE_C_FLAGS="-fcf-protection=none".
The manual override of CMAKE_C_FLAGS shouldn't be needed, if you rerun
cmake from a clean slate (removing the CMakeCache.txt, etc) it should
detect that "-fcf-protection=branch" is hard-wired on, and wi
Thank you for your guidance, now I can successfully compile and link gollvm
by setting CMAKE_C_FLAGS="-fcf-protection=none". But after installing
gollvm, there is still a weird problem:
root@a78010e8da5d:~# go version
go: symbol lookup error:
/root/llvm-project/install-release/lib64/libgo.so.11
This looks exactly like the bug in https://github.com/golang/go/issues/38728.
The prolog of the function contains
0: f3 0f 1e fa endbr64
which is confusing the gold linker. This instruction doesn't get added
unless the host compiler has "-fcf-protection=branch" turned on. I would
su
OK, as follows
./tools/gollvm/libgo/CMakeFiles/libgo_c_piclib.dir/__/gofrontend/libgo/go/syscall/errno.c.o:
file format elf64-x86-64
Disassembly of section .text.syscall.GetErrno:
:
0: f3 0f 1e fa endbr64
4: 64 48 3b 24 25 70 00 cmp%fs:0x70,%rsp
b: 0
OK. Just to confirm, what do you see from
objdump -dr
./tools/gollvm/libgo/CMakeFiles/libgo_c_piclib.dir/__/gofrontend/libgo/go/syscall/errno.c.o
for the prolog of syscall.Geterrno. Should be something like
Disassembly of section .text.syscall.GetErrno:
:
0: 64 48 3b 24 25
Fine, that is
[1/3] /usr/bin/cc -D_DEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS
-D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Itools/gollvm/libgo
-I/root/llvm-project/llvm/tools/gollvm/libgo -Iinclude
-I/root/llvm-project/llvm/include
-I/root/llvm-project/llvm/tools/gollvm/gofrontend/libgo/run
OK.
I'm wondering if for some reason the fix I put in is not effective.
Could you please try this in your build area:
rm
./tools/gollvm/libgo/CMakeFiles/libgo_c_piclib.dir/__/gofrontend/libgo/go/syscall/errno.c.o
ninja -v libgo_all
and post the compile line for errno.c?
Thanks, Than
On Tue
Yes, I'm sure I fetched the last version of gollvm,
i.e. 0edc44a02852dd0d56cac35163a45634b497d6cd
On Tuesday, May 26, 2020 at 6:55:08 PM UTC+8, Than McIntosh wrote:
>
> Hello,
>
> The ld.gold error message looks a lot like one reported in a previous bug,
> https://github.com/golang/go/issues/387
Hello,
The ld.gold error message looks a lot like one reported in a previous bug,
https://github.com/golang/go/issues/38728.
Can you please check to make sure that your client is sync'd past the CLs
that fix this issue, e.g. 0edc44a02852dd0d56cac35163a45634b497d6cd.
Thanks, Than
On Mon, May 25
I tried to build gollvm in a docker container (the image is based on ubuntu
20.04, and the host OS is MacOS catalina). I configured llvm by
SHELL=/bin/sh cmake -DCMAKE_BUILD_TYPE=Release -DLLVM_TARGETS_TO_BUILD=X86
-DLLVM_ENABLE_ASSERTIONS=On -DLLVM_ENABLE_RTTI=On -DLLVM_USE_LINKER=gold -G
Ninj
13 matches
Mail list logo
