Re: [go-nuts] [gollvm] Are there any plans to sync with LLVM16 or above?

['Than McIntosh' via golang-nuts]

Hi Sophie,

Thanks for the question.

The chief blocker for updating gollvm to later versions of LLVM trunk is
dealing with LLVM's opaque pointer migration
 in the gollvm bridge

source code. The bridge (which maps from gofrontend's IR to LLVM IR) was
written prior to opaque pointers and it assumes that given an LLVM type T,
it can always ask for what T points to (which is exactly what you can't do
under the opaque pointer model).

Fixing this is not a huge amounts of work (maybe a few weeks? hard to tell)
but the folks with the highest level of gollvm expertise have been tied up
with other more important priorities.

So to answer your question, no plans in the short term.  I could provide
some limited help (pointers etc) but I don't have the time to make a
significant investment in this at the moment.

Thanks, Than

On Mon, Feb 26, 2024 at 12:57 AM sophie zhao 
wrote:

> Hello,
> We want to add support for the loongarch architecture to gollvm, which
> requires using an LLVM version that supports loongarch (that is, a version
> >= 16.0.0). The current gollvm only syncs with LLVM trunk at 09629215c272.
> We did some work synchronizing LLVM locally, but it wasn't enough. We would
> like to ask if the community has any work plan to synchronize LLVM. If
> necessary, we can also join in this work.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/b9ff523c-1e13-43a4-bb22-03ca46e84c7fn%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BUr55G9nUHo-n3PefAOhs6sVcb16N%2BRTmqrvE-CJbXv4ZANMQ%40mail.gmail.com.

Re: [go-nuts] [GOLLVM] Running LLI on LLVM Bitcode Fails with Recommended Setting

['Than McIntosh' via golang-nuts]

Hi,

Looks like things are crashing while trying to read your bitcode, but other
than that I am not sure what the issue might be ( I don't think I have seen
that failure mode before). Sorry, this is not super helpful.

Best regards, Than


On Tue, Aug 8, 2023 at 11:10 PM Md. Sakib Anwar 
wrote:

> Hello,
> I am trying to follow this commit of gofrontend: 140917: runtime: hack to
> make LLVM's lli work
> . For LLVM,
> GO-LLVM, LIBFFI and LIBBACKTRACE I am following the recommended commits as
> well:
>
> GOLLVM_COMMIT=3452ec6bebaa1b432aabed1991475fc1775e
> LIBBACKTRACE_COMMIT=fd9442f7b5413e7788dfcf356f6261afcedb56e8
> LIBFFI_COMMIT=2e825e219fa06d308b9a9863d70320606d67490d
> LLVM_COMMIT=09629215c272f09e3ebde6cc7eac9625d28910ff
>
> LLI VERSION: LLVM (http://llvm.org/):
>   LLVM version 13.0.1
>   Optimized build with assertions.
>   Default target: x86_64-unknown-linux-gnu
>   Host CPU: goldmont
>
> However, even after following and applying the required patch to make them
> work, I am unable to reproduce the expected result as mentioned in the
> gofrontend hack. The error I am getting is: :
>
> Error opening './gollvm/lib64/libgo.so.15git':
> ./gollvm/lib64/libgo.so.15git: undefined symbol: main.main
>   -load request ignored.
> lli: /tmp/llvm-130/llvm/lib/Bitcode/Reader/MetadataLoader.cpp:366:
> {anonymous}::{anonymous}::PlaceholderQueue::~PlaceholderQueue(): Assertion
> `empty() && "PlaceholderQueue hasn't been flushed before being destroyed"'
> failed.
> PLEASE submit a bug report to https://bugs.llvm.org/ and include the
> crash backtrace.
> Stack dump:
> 0.  Program arguments: lli -load=./gollvm/lib64/libgo.so.15git
> -extra-module=hello.bc newmain.bc
>  #0 0x7f91db4c0e66 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int)
> /tmp/llvm-130/llvm/lib/Support/Unix/Signals.inc:569:3
>  #1 0x7f91db4bee64 llvm::sys::RunSignalHandlers()
> /tmp/llvm-130/llvm/lib/Support/Signals.cpp:97:20
>  #2 0x7f91db4befe6 SignalHandler(int)
> /tmp/llvm-130/llvm/lib/Support/Unix/Signals.inc:407:1
>  #3 0x7f91da973520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
>  #4 0x7f91da9c7a7c pthread_kill
> (/lib/x86_64-linux-gnu/libc.so.6+0x96a7c)
>  #5 0x7f91da973476 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x42476)
>  #6 0x7f91da9597f3 abort (/lib/x86_64-linux-gnu/libc.so.6+0x287f3)
>  #7 0x7f91da95971b (/lib/x86_64-linux-gnu/libc.so.6+0x2871b)
>  #8 0x7f91da96ae96 (/lib/x86_64-linux-gnu/libc.so.6+0x39e96)
>  #9 0x7f91dc0a90e1
> (/tmp/llvm-130-install_O_D_A/bin/../lib/libLLVM-13.so+0x13210e1)
> #10 0x7f91dc0ba14b llvm::SmallVectorTemplateCommon void>::begin() /tmp/llvm-130/llvm/include/llvm/ADT/SmallVector.h:253:45
> #11 0x7f91dc0ba14b llvm::SmallVectorTemplateCommon void>::end() /tmp/llvm-130/llvm/include/llvm/ADT/SmallVector.h:255:32
> #12 0x7f91dc0ba14b llvm::SmallVector 64u>::~SmallVector()
> /tmp/llvm-130/llvm/include/llvm/ADT/SmallVector.h:1175:24
> #13 0x7f91dc0ba14b
> llvm::MetadataLoader::MetadataLoaderImpl::parseMetadata(bool)
> /tmp/llvm-130/llvm/lib/Bitcode/Reader/MetadataLoader.cpp:1058:1
> #14 0x7f91dc0baa38 llvm::MetadataLoader::parseMetadata(bool)
> /tmp/llvm-130/llvm/lib/Bitcode/Reader/MetadataLoader.cpp:2319:1
> #15 0x7f91dc09b362 llvm::Error::setChecked(bool)
> /tmp/llvm-130/llvm/include/llvm/Support/Error.h:305:22
> #16 0x7f91dc09b362 llvm::Error::operator bool()
> /tmp/llvm-130/llvm/include/llvm/Support/Error.h:236:15
> #17 0x7f91dc09b362 (anonymous
> namespace)::BitcodeReader::parseModule(unsigned long, bool,
> llvm::function_ref std::char_traits, std::allocator > > (llvm::StringRef)>)
> /tmp/llvm-130/llvm/lib/Bitcode/Reader/BitcodeReader.cpp:3612:56
> #18 0x7f91dc0a81db llvm::Error::setChecked(bool)
> /tmp/llvm-130/llvm/include/llvm/Support/Error.h:305:22
> #19 0x7f91dc0a81db llvm::Error::operator bool()
> /tmp/llvm-130/llvm/include/llvm/Support/Error.h:236:15
> #20 0x7f91dc0a81db
> llvm::BitcodeModule::getModuleImpl(llvm::LLVMContext&, bool, bool, bool,
> llvm::function_ref std::char_traits, std::allocator > > (llvm::StringRef)>)
> /tmp/llvm-130/llvm/lib/Bitcode/Reader/BitcodeReader.cpp:6790:71
> #21 0x7f91dc0a84f5
> llvm::Expected::assertIsChecked() const
> /tmp/llvm-130/llvm/include/llvm/Support/Error.h:708:9
> #22 0x7f91dc0a84f5 llvm::Expected::~Expected()
> /tmp/llvm-130/llvm/include/llvm/Support/Error.h:554:20
> #23 0x7f91dc0a84f5 llvm::parseBitcodeFile(llvm::MemoryBufferRef,
> llvm::LLVMContext&,
> llvm::function_ref std::char_traits, std::allocator > > (llvm::StringRef)>)
> /tmp/llvm-130/llvm/lib/Bitcode/Reader/BitcodeReader.cpp:6990:1
> #24 0x7f91db70abc9 llvm::Expected std::default_delete > >::takeError()
> /tmp/llvm-130/llvm/include/llvm/Support/Error.h:592:15
> #25 0x7f91db70abc9 llvm::parseIR(llvm::MemoryBufferRef,
> llvm::SMDiagnostic&, llvm::LLVMContext&,
> llvm::function_ref std::char_traits, std::allocator > > (llvm::StringRef)>)
> 

Re: [go-nuts] Using LLVM based fuzzing tools (KLEE) on IR produced by gollvm

['Than McIntosh' via golang-nuts]

Hello,

I assume that the fuzzing works by running the LLVM bitcode through the
interpreter? If so then these threads here are related:

https://groups.google.com/g/golang-nuts/c/raheTfR_Syk/m/-9FaVnKqAwAJ
https://groups.google.com/g/golang-nuts/c/9lSni3jhXhA/m/KQzlRJtoBAAJ

As you can see from https://go-review.googlesource.com/c/gofrontend/+/140917,
running gollvm programs via the interpreter is kind of a research project
at the moment, requires a lot of hacks. This is a use case that we haven't
really fully fleshed out.

Regards, Than


On Fri, May 26, 2023 at 12:49 PM Mircea Preoteasa <
mircea.preoteasa2...@gmail.com> wrote:

> Hello, I have recently started fiddling around with the gollvm compiler
> with the end goal of being able to fuzz test Go programs with LLVM based
> tools such as KLEE [1]. Here's what I did:
>
> 1.)  Compiled gollvm and installed KLEE from the official repositories
> under the Fedora 37 official docker image
> 2.) Used llvm-goc to emit llvm IR for a sample Go program (attached below)
> (adapted from KLEE's get sign example), then llvm-as to convert that to
> bitcode
>
> Running KLEE on the resulting bitcode, it seems that it can't find any of
> the Go runtime symbols (see screenshot attached). My supposition is that I
> might need to recompile the Go runtime to LLVM bitcode in order to get this
> working. Is this correct? If yes, how would I go about doing that?
>
> [1]: https://klee.github.io/
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/83933628-8cf9-4927-afab-ead514702ba8n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BUr55FmivBTN3gX5LP3rzFwgVGOp6Xj-SFcpPLBCaW7W-6LMw%40mail.gmail.com.

Re: [go-nuts] gollvm build fails

['Than McIntosh' via golang-nuts]

Hello,

The gollvm build with LLVM tip is currently broken; there have been some
upstream LLVM changes that aren't compatible with the Gollvm bridge code
(notably the opaque pointer migration), which causes build failures.  This
is a known problem, I haven't had enough free time to fix it recently.

I suggest building with slightly older versions of the LLVM and related
repos. For example, this should work:

gollvm commit:  3452ec6bebaa1b432aabed1991475fc1775e
libbacktrace commit:  fd9442f7b5413e7788dfcf356f6261afcedb56e8
libffi commit:  2e825e219fa06d308b9a9863d70320606d67490d
gofrontend commit 1c5bfd57131b68b91d8400bb017f35d416f7aa7b
llvm-project commit 09629215c272f09e3ebde6cc7eac9625d28910ff

Let me know if you have issues building with this setup.

Thanks, Than


On Tue, Jan 31, 2023 at 1:04 AM 张勇强  wrote:

> I build gollvm on linux.  Is gollvm depend on a fiexed version of llvm?
> what's the version? thx
> -- Retry after 5 seconds (attempt #3) ...
> /home/zyq/strength/gollvm/workarea/llvm-project/llvm/tools/gollvm/passes/GC.cpp:47:3:
> 错误：‘Optional’不是一个类型名
>47 |   Optional isGCManagedPointer(const Type *Ty) const override
> {
>   |   ^~~~
> /home/zyq/strength/gollvm/workarea/llvm-project/llvm/tools/gollvm/passes/GC.cpp:
> 在函数‘void emitCallsiteEntries(llvm::StackMaps&, llvm::MCStreamer&)’中:
> /home/zyq/strength/gollvm/workarea/llvm-project/llvm/tools/gollvm/passes/GC.cpp:174:29:
> 错误：cannot convert ‘int’ to ‘llvm::Align’
>   174 | OS.emitValueToAlignment(8);
>   | ^
>   | |
>   | int
> In file included from
> /home/zyq/strength/gollvm/workarea/llvm-project/llvm/tools/gollvm/passes/GC.cpp:25:
> /home/zyq/strength/gollvm/workarea/llvm-project/llvm/include/llvm/MC/MCStreamer.h:861:43:
> 附注：  初始化‘virtual void llvm::MCStreamer::emitValueToAlignment(llvm::Align,
> int64_t, unsigned int, unsigned int)’的实参 1
>   861 |   virtual void emitValueToAlignment(Align Alignment, int64_t Value
> = 0,
>   | ~~^
> /home/zyq/strength/gollvm/workarea/llvm-project/llvm/tools/gollvm/passes/GC.cpp:
> 在成员函数‘virtual bool
> {anonymous}::GoGCPrinter::emitStackMaps(llvm::StackMaps&,
> llvm::AsmPrinter&)’中:
> /home/zyq/strength/gollvm/workarea/llvm-project/llvm/tools/gollvm/passes/GC.cpp:186:6:
> 错误：‘class llvm::MCStreamer’ has no member named ‘SwitchSection’; did you
> mean ‘switchSection’?
>   186 |   OS.SwitchSection(StackMapSection);
>   |  ^
>   |  switchSection
> /home/zyq/strength/gollvm/workarea/llvm-project/llvm/tools/gollvm/passes/GoStatepoints.cpp:1265:15:
> 错误：‘ArgMemOnly’不是‘llvm::Attribute’的成员
>  1265 |Attribute::ArgMemOnly, Attribute::InaccessibleMemOnly,
>   |   ^~
> /home/zyq/strength/gollvm/workarea/llvm-project/llvm/tools/gollvm/passes/GoStatepoints.cpp:1265:38:
> 错误：‘InaccessibleMemOnly’不是‘llvm::Attribute’的成员
>  1265 |Attribute::ArgMemOnly, Attribute::InaccessibleMemOnly,
>   |  ^~~
> /home/zyq/strength/gollvm/workarea/llvm-project/llvm/tools/gollvm/passes/GoStatepoints.cpp:1266:15:
> 错误：‘InaccessibleMemOrArgMemOnly’不是‘llvm::Attribute’的成员
>  1266 |Attribute::InaccessibleMemOrArgMemOnly,
>   |   ^~~
> /home/zyq/strength/gollvm/workarea/llvm-project/llvm/tools/gollvm/passes/GoStatepoints.cpp:
> 在函数‘void makeStatepointExplicitImpl(llvm::CallBase*,
> llvm::SmallVectorImpl&, llvm::SmallVectorImpl&,
> {anonymous}::PartiallyConstructedSafepointRecord&,
> std::vector<{anonymous}::DeferredReplacement>&)’中:
> /home/zyq/strength/gollvm/workarea/llvm-project/llvm/tools/gollvm/passes/GoStatepoints.cpp:1433:50:
> 错误：‘class llvm::PointerType’ has no member named ‘getElementType’; did you
> mean ‘getArrayElementType’?
>  1433 |   Type *T = cast(V->getType())->getElementType();
>   |  ^~
>   |
>  getArrayElementType
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/2d6a3e36-ea7a-475e-9994-5ecf1d393021n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BUr55EE54Y0X_vRrJyCcovEo9ZyTZY_T4GMT3Gas0spuWQC1g%40mail.gmail.com.

Re: [go-nuts] GoLLVM: using the result of `go build -x . ` to rebuild the program got failed

['Than McIntosh' via golang-nuts]

>/data/mygo/gollvm_workarea/install/bin/llvm-goc: error: unrecognized
command line option '-fgo-importcfg=/dev/null'

The Go command only passes this option to the compiler if it thinks that
the compiler is the main go compiler ("gc") as opposed to gollvm. What
output do you get when you run "go version" ?

Thanks, Than


On Thu, Oct 27, 2022 at 12:05 PM 'Qingwei Li' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> the GoLLVM is based on LLVM 15.0.0
>
> Example to reproduce:
> The structure of project is as follows:
>
> ```
> easyPkg/
> ├── go.mod
> ├── main.go
> └── Pkg
> └── utils.go
> ```
>
> main.go
>
> ```
> package main
>
> import "easyPkg/Pkg"
>
> func main() {
> Pkg.PkgFunc()
> }
> ```
>
> utils.go
>
> ```
> package Pkg
>
> func PkgFunc() {
> println("pkgFunc")
> }
> ```
>
> go.mod
>
> ```
> module easyPkg
>
> go 1.18
> ```
>
> use `go build -x . 2> auto.sh` to get the building process. Then delete
> the generated binary file `easyPkg` and use `go clean -cache` to clean the
> building cache. Then I use the command `source auto.sh` to regenerate the
> binary, which fails.
>
> part of the error log is as follows
>
> ```
> /data/mygo/gollvm_workarea/install/bin/llvm-goc: error: unrecognized
> command line option '-fgo-importcfg=/dev/null'
> /data/mygo/gollvm_workarea/install/bin/llvm-goc: error: unrecognized
> command line option '-ffile-prefix-map=a=b'
> ./main.go:3:19: error:
> /tmp/go-build3415416681/b001/_importcfgroot_/easyPkg/libPkg.a exists but
> does not contain any Go export data
> ./main.go:3:19: warning: easyPkg/Pkg: Not a directory
> ./main.go:3:19: error: import file 'easyPkg/Pkg' not found
> ./main.go:6:2: error: reference to undefined name 'Pkg'
> /usr/bin/ld.gold: error: /tmp/go-build3415416681/b001/_pkg_.a: member at
> 72 is not an ELF object
> /usr/bin/ld.gold: error: /tmp/go-build3415416681/b002/_pkg_.a: member at
> 72 is not an ELF object
> buildid: open /tmp/go-build3415416681/b001/exe/a.out: no such file or
> directory
> ```
>
> what can I do on the auto.sh script to regenerate the binary file? Is the
> process dumped completed?
>
> On a single package with no subdirectory, the result of `go build -x .` is
> available for regenerating the binary file.
>
> Moreover, my main purpose is to add -emit-llvm option wherever `llvm-goc`
> appears and use `llvm-link -S` to link all object files generated by
> llvm-goc to get a whole LLVM IR file for the whole project. If the question
> above is now insoluble, is there any other way to get the whole project's
> LLVM IR?
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/b120de38-d603-4a8d-a029-34351abc051cn%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BUr55ENsDS_zpp0TCeyJDfh7jO%2B%3DQOcrfNs1zxqNBYjpPPvDw%40mail.gmail.com.

Re: [go-nuts] gollvm build fails

['Than McIntosh' via golang-nuts]

Weird. I am scratching my head.

At this point if I was debugging it myself on your system I would rerun
cmake passing it the "--trace-expand" flag (which will generate giant
volumes of output), then look in the trace to see what is happening when
the cmake rules in question fire. You should see something like

...
/mybuildarea/llvm-project/llvm/tools/gollvm/libgo/CMakeLists.txt(232):
 set(zgoarchdotgo ${libgo_binroot}/zgoarch.go )
/mybuildarea/llvm-project/llvm/tools/gollvm/libgo/CMakeLists.txt(233):
 set(zgoarchtmp ${libgo_binroot}/zgoarch.go.tmp )
/mybuildarea/llvm-project/llvm/tools/gollvm/libgo/CMakeLists.txt(234):
 mkzgoarch(${goarch} ${zgoarchtmp} ${libgo_scriptroot} )
/mybuildarea/llvm-project/llvm/tools/gollvm/cmake/modules/AutoGenGo.cmake(75):
 file(REMOVE ${outfile} )
/mybuildarea/llvm-project/llvm/tools/gollvm/cmake/modules/AutoGenGo.cmake(76):
 file(WRITE ${outfile} package goarch\n\n )
/mybuildarea/llvm-project/llvm/tools/gollvm/cmake/modules/AutoGenGo.cmake(78):
 file(APPEND ${outfile} const GOARCH = \"${goarch}\"\n\n )
...

If these rules are not firing, then hopefully the trace output will have
some suggestion as to why.

Thanks, Than




On Tue, Oct 25, 2022 at 3:29 AM Alex Markin  wrote:

> > Do you have tools/gollvm/libgo/zgoarch.go.tmp in your build area? What
> sort of content is in that file?
>
> No
>
> $ ninja -v -d explain tools/gollvm/libgo/zgoarch.go
> ninja: error: unknown target 'tools/gollvm/libgo/zgoarch.go'
>
> $ gcc -dumpmachine
> x86_64-pc-linux-gnu
>
> $ clang -dumpmachine
> x86_64-pc-linux-gnu
>
> I tried manually setting up different target triples (for example the same
> as on a working machine) but
> it did not help.
>
>
> чт, 20 окт. 2022 г. в 15:48, Than McIntosh :
>
>> >There is no zgoarch.go file in the build area. It seems that it was not
>> created by the build system.
>>
>> I've oversimplified things a bit -- what cmake does is write
>> out tools/gollvm/libgo/zgoarch.go.tmp, and then add a build rule
>> for zgoarch.go that copies the *.tmp file to the *.go file if they are
>> different.
>>
>> Do you have tools/gollvm/libgo/zgoarch.go.tmp in your build area? What
>> sort of content is in that file? What happens when you do
>>
>>$ ninja -v -d explain tools/gollvm/libgo/zgoarch.go
>>
>> You should see something like
>>
>> ninja explain: output tools/gollvm/libgo/zgoarch.go doesn't exist
>> [1/1] cd /x/llvm-project/build-relwithdbg/tools/gollvm/libgo &&
>> /usr/bin/cmake -E copy_if_different
>> /x/llvm-project/build-relwithdbg/tools/gollvm/libgo/zgoarch.go.tmp
>> /x/llvm-project/build-relwithdbg/tools/gollvm/libgo/zgoarch.go
>>
>> Thanks, Than
>>
>>
>>
>>
>> On Wed, Oct 19, 2022 at 5:42 PM Alex Markin  wrote:
>>
>>> There is no zgoarch.go file in the build area. It seems that it was not
>>> created by the build system. I watched the logs and there were no lines to
>>> create it. In the directory libgo I have only the following *go files:
>>>
>>> epoll.go  goroot.go  libcalls.go  syscall_arch.go  tmp-libcalls.go
>>>
>>> So I can't understand why the rule for zgoarch is not called. Probably
>>> some env variable?
>>>
>>> ср, 19 окт. 2022 г. в 16:47, Than McIntosh :
>>>
 Hi,

 Those constants are supposed to be defined in the generated file
 /tools/gollvm/libgo/zgoarch.go, which is written as out part of
 the gollvm build process, e.g. here


 https://go.googlesource.com/gollvm/+/253c122ed62d5e9a32a9806e83c47a389a6435bf/cmake/modules/AutoGenGo.cmake#63

 What does the zgoarch.go file look like in your build area?

 Thanks, Than


 On Wed, Oct 19, 2022 at 8:20 AM Alex Markin 
 wrote:

> Hello.
>
> I'm trying to build gollvm on my gentoo system and get the following
> error:
>
> FAILED: tools/gollvm/libgo/internal/.pic/goarch.o
> /home/alex/test/gollvm/build-debug/tools/gollvm/libgo/internal/.pic/goarch.o
>
> cd /home/alex/test/gollvm/build-debug/tools/gollvm/libgo &&
> /usr/bin/cmake -E make_directory ./internal/.pic &&
> /home/alex/test/gollvm/build-debug/./bin/llvm
> -goc -c -o
> /home/alex/test/gollvm/build-debug/tools/gollvm/libgo/internal/.pic/goarch.o
> -fPIC -fgo-pkgpath=internal/goarch -I . /home/alex/test/gollvm/llvm-p
> roject/llvm/tools/gollvm/gofrontend/libgo/go/internal/goarch/goarch.go
> /home/alex/test/gollvm/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/internal/goarch/goarch.go:15:35:
> error: reference to undefined name '_ArchFamily'
> /home/alex/test/gollvm/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/internal/goarch/goarch.go:18:19:
> error: reference to undefined name '_BigEndian'
> /home/alex/test/gollvm/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/internal/goarch/goarch.go:21:29:
> error: reference to undefined name '_DefaultPhysPa
> geSize'
> /home/alex/test/gollvm/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/internal/goarch/goarch.go:25:19:
> error: 

Re: [go-nuts] gollvm build fails

['Than McIntosh' via golang-nuts]

>There is no zgoarch.go file in the build area. It seems that it was not
created by the build system.

I've oversimplified things a bit -- what cmake does is write
out tools/gollvm/libgo/zgoarch.go.tmp, and then add a build rule
for zgoarch.go that copies the *.tmp file to the *.go file if they are
different.

Do you have tools/gollvm/libgo/zgoarch.go.tmp in your build area? What sort
of content is in that file? What happens when you do

   $ ninja -v -d explain tools/gollvm/libgo/zgoarch.go

You should see something like

ninja explain: output tools/gollvm/libgo/zgoarch.go doesn't exist
[1/1] cd /x/llvm-project/build-relwithdbg/tools/gollvm/libgo &&
/usr/bin/cmake -E copy_if_different
/x/llvm-project/build-relwithdbg/tools/gollvm/libgo/zgoarch.go.tmp
/x/llvm-project/build-relwithdbg/tools/gollvm/libgo/zgoarch.go

Thanks, Than




On Wed, Oct 19, 2022 at 5:42 PM Alex Markin  wrote:

> There is no zgoarch.go file in the build area. It seems that it was not
> created by the build system. I watched the logs and there were no lines to
> create it. In the directory libgo I have only the following *go files:
>
> epoll.go  goroot.go  libcalls.go  syscall_arch.go  tmp-libcalls.go
>
> So I can't understand why the rule for zgoarch is not called. Probably
> some env variable?
>
> ср, 19 окт. 2022 г. в 16:47, Than McIntosh :
>
>> Hi,
>>
>> Those constants are supposed to be defined in the generated file
>> /tools/gollvm/libgo/zgoarch.go, which is written as out part of
>> the gollvm build process, e.g. here
>>
>>
>> https://go.googlesource.com/gollvm/+/253c122ed62d5e9a32a9806e83c47a389a6435bf/cmake/modules/AutoGenGo.cmake#63
>>
>> What does the zgoarch.go file look like in your build area?
>>
>> Thanks, Than
>>
>>
>> On Wed, Oct 19, 2022 at 8:20 AM Alex Markin  wrote:
>>
>>> Hello.
>>>
>>> I'm trying to build gollvm on my gentoo system and get the following
>>> error:
>>>
>>> FAILED: tools/gollvm/libgo/internal/.pic/goarch.o
>>> /home/alex/test/gollvm/build-debug/tools/gollvm/libgo/internal/.pic/goarch.o
>>>
>>> cd /home/alex/test/gollvm/build-debug/tools/gollvm/libgo &&
>>> /usr/bin/cmake -E make_directory ./internal/.pic &&
>>> /home/alex/test/gollvm/build-debug/./bin/llvm
>>> -goc -c -o
>>> /home/alex/test/gollvm/build-debug/tools/gollvm/libgo/internal/.pic/goarch.o
>>> -fPIC -fgo-pkgpath=internal/goarch -I . /home/alex/test/gollvm/llvm-p
>>> roject/llvm/tools/gollvm/gofrontend/libgo/go/internal/goarch/goarch.go
>>> /home/alex/test/gollvm/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/internal/goarch/goarch.go:15:35:
>>> error: reference to undefined name '_ArchFamily'
>>> /home/alex/test/gollvm/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/internal/goarch/goarch.go:18:19:
>>> error: reference to undefined name '_BigEndian'
>>> /home/alex/test/gollvm/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/internal/goarch/goarch.go:21:29:
>>> error: reference to undefined name '_DefaultPhysPa
>>> geSize'
>>> /home/alex/test/gollvm/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/internal/goarch/goarch.go:25:19:
>>> error: reference to undefined name '_PCQuantum'
>>> /home/alex/test/gollvm/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/internal/goarch/goarch.go:28:20:
>>> error: reference to undefined name '_Int64Align'
>>> /home/alex/test/gollvm/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/internal/goarch/goarch.go:35:22:
>>> error: reference to undefined name '_MinFrameSize'
>>> /home/alex/test/gollvm/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/internal/goarch/goarch.go:39:20:
>>> error: reference to undefined name '_StackAlign'
>>>
>>> What can be the reason of such error? On another ubuntu system
>>> everything goes correctly.
>>>
>>> The cmake line:
>>>
>>> cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_CXX_COMPILER=clang++
>>> -DCMAKE_C_COMPILER=clang -G Ninja ../llvm-project/llvm
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to golang-nuts+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/9ad0d8dc-d118-45d2-984e-9cdf36ab4f28n%40googlegroups.com
>>> 
>>> .
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BUr55EJFXZth7yPxKMTcaY4osOV9DW_qkRuLpXt9U3_nJWq-g%40mail.gmail.com.

Re: [go-nuts] gollvm build fails

['Than McIntosh' via golang-nuts]

Hi,

Those constants are supposed to be defined in the generated file
/tools/gollvm/libgo/zgoarch.go, which is written as out part of
the gollvm build process, e.g. here

https://go.googlesource.com/gollvm/+/253c122ed62d5e9a32a9806e83c47a389a6435bf/cmake/modules/AutoGenGo.cmake#63

What does the zgoarch.go file look like in your build area?

Thanks, Than


On Wed, Oct 19, 2022 at 8:20 AM Alex Markin  wrote:

> Hello.
>
> I'm trying to build gollvm on my gentoo system and get the following error:
>
> FAILED: tools/gollvm/libgo/internal/.pic/goarch.o
> /home/alex/test/gollvm/build-debug/tools/gollvm/libgo/internal/.pic/goarch.o
>
> cd /home/alex/test/gollvm/build-debug/tools/gollvm/libgo && /usr/bin/cmake
> -E make_directory ./internal/.pic &&
> /home/alex/test/gollvm/build-debug/./bin/llvm
> -goc -c -o
> /home/alex/test/gollvm/build-debug/tools/gollvm/libgo/internal/.pic/goarch.o
> -fPIC -fgo-pkgpath=internal/goarch -I . /home/alex/test/gollvm/llvm-p
> roject/llvm/tools/gollvm/gofrontend/libgo/go/internal/goarch/goarch.go
> /home/alex/test/gollvm/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/internal/goarch/goarch.go:15:35:
> error: reference to undefined name '_ArchFamily'
> /home/alex/test/gollvm/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/internal/goarch/goarch.go:18:19:
> error: reference to undefined name '_BigEndian'
> /home/alex/test/gollvm/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/internal/goarch/goarch.go:21:29:
> error: reference to undefined name '_DefaultPhysPa
> geSize'
> /home/alex/test/gollvm/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/internal/goarch/goarch.go:25:19:
> error: reference to undefined name '_PCQuantum'
> /home/alex/test/gollvm/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/internal/goarch/goarch.go:28:20:
> error: reference to undefined name '_Int64Align'
> /home/alex/test/gollvm/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/internal/goarch/goarch.go:35:22:
> error: reference to undefined name '_MinFrameSize'
> /home/alex/test/gollvm/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/internal/goarch/goarch.go:39:20:
> error: reference to undefined name '_StackAlign'
>
> What can be the reason of such error? On another ubuntu system everything
> goes correctly.
>
> The cmake line:
>
> cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_CXX_COMPILER=clang++
> -DCMAKE_C_COMPILER=clang -G Ninja ../llvm-project/llvm
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/9ad0d8dc-d118-45d2-984e-9cdf36ab4f28n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BUr55GV3enisrghVbCjf0FauPif3mPgMOrzPCMUBBpK2LdUsQ%40mail.gmail.com.

Re: [go-nuts] [gollvm] build fail

['Than McIntosh' via golang-nuts]

Apologies, looks like I picked the wrong LLVM hash. Please try

llvm-project commit 09629215c272f09e3ebde6cc7eac9625d28910ff

Cheers Than


On Mon, May 16, 2022 at 10:38 AM Than McIntosh  wrote:

> Hi,
>
> Thanks for your interest in Gollvm.
>
> The gollvm build is broken at tip at the moment;  due to competing demands
> on my time, I haven't been able to work on this problem. Your patience is
> abbreviated.
>
> For now I suggest building with slightly older versions of the LLVM and
> related repos. For example, this should work:
>
> gollvm commit:  0e34e09fc15cde73f1b9974f2a657360abb94b4f
> libbacktrace commit:  2446c66076480ce07a6bd868badcbceb3eeecc2e
> libffi commit:  ab1677106605aba1c27665964ff90bea59612ce3
> gofrontend commit 7f33baa09a8172bb2c5f1ca0435d9efe3e194c9b
> llvm-project commit 0ac213667df1afbba3f66cb4fc3ec51073b9c158
>
> Thanks, Than
>
>
> On Mon, May 16, 2022 at 9:41 AM Honlim Chan  wrote:
>
>> clang version 10.0.0-4ubuntu1
>> build commands: cmake -DCMAKE_C_COMPILER=clang
>> -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_INSTALL_PREFIX=/compiler/gollvm
>> -DCMAKE_BUILD_TYPE=Release -DLLVM_USE_LINKER=gold -G Ninja
>> ../llvm-project/llvm
>> ninja gollvm
>>
>> [2184/3879] Building CXX object
>> tools/gollvm/passes/CMakeFiles/LLVMCppGoPasses.dir/GoStatepoints.cpp.o
>> FAILED:
>> tools/gollvm/passes/CMakeFiles/LLVMCppGoPasses.dir/GoStatepoints.cpp.o
>> /usr/bin/clang++ -DGTEST_HAS_RTTI=0 -D_GNU_SOURCE
>> -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
>> -I/home/jenkins/test/build.rel/tools/gollvm/passes
>> -I/home/jenkins/test/llvm-project/llvm/tools/gollvm/passes
>> -I/home/jenkins/test/build.rel/include
>> -I/home/jenkins/test/llvm-project/llvm/include -fPIC
>> -fvisibility-inlines-hidden -Werror=date-time
>> -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter
>> -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic
>> -Wno-long-long -Wc++98-compat-extra-semi -Wimplicit-fallthrough
>> -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor
>> -Wdelete-non-virtual-dtor -Wstring-conversion -Wmisleading-indentation
>> -fdiagnostics-color -ffunction-sections -fdata-sections -O3 -DNDEBUG
>>  -fno-exceptions -fno-rtti -std=c++14 -MD -MT
>> tools/gollvm/passes/CMakeFiles/LLVMCppGoPasses.dir/GoStatepoints.cpp.o -MF
>> tools/gollvm/passes/CMakeFiles/LLVMCppGoPasses.dir/GoStatepoints.cpp.o.d -o
>> tools/gollvm/passes/CMakeFiles/LLVMCppGoPasses.dir/GoStatepoints.cpp.o -c
>> /home/jenkins/test/llvm-project/llvm/tools/gollvm/passes/GoStatepoints.cpp
>> /home/jenkins/test/llvm-project/llvm/tools/gollvm/passes/GoStatepoints.cpp:1286:31:
>> error: no member named 'getFnAttrs' in 'llvm::AttributeList'
>>   AttrBuilder FnAttrs(Ctx, AL.getFnAttrs());
>>~~ ^
>> /home/jenkins/test/llvm-project/llvm/tools/gollvm/passes/GoStatepoints.cpp:1290:25:
>> error: no member named 'getFnAttrs' in 'llvm::AttributeList'
>>   for (Attribute A : AL.getFnAttrs()) {
>>  ~~ ^
>> /home/jenkins/test/llvm-project/llvm/tools/gollvm/passes/GoStatepoints.cpp:1516:34:
>> error: no matching member function for call to 'CreateGCStatepointInvoke'
>> InvokeInst *Invoke = Builder.CreateGCStatepointInvoke(
>>  ^~~~
>> /home/jenkins/test/llvm-project/llvm/include/llvm/IR/IRBuilder.h:836:3:
>> note: candidate function not viable: no known conversion from
>> 'llvm::FunctionCallee' to 'llvm::Value *' for 3rd argument
>>   CreateGCStatepointInvoke(uint64_t ID, uint32_t NumPatchBytes,
>>   ^
>> /home/jenkins/test/llvm-project/llvm/include/llvm/IR/IRBuilder.h:817:3:
>> note: candidate function not viable: no known conversion from
>> 'llvm::FunctionCallee' to 'llvm::Value *' for 3rd argument
>>   CreateGCStatepointInvoke(uint64_t ID, uint32_t NumPatchBytes,
>>   ^
>> /home/jenkins/test/llvm-project/llvm/include/llvm/IR/IRBuilder.h:825:15:
>> note: candidate function not viable: requires at least 10 arguments, but 9
>> were provided
>>   InvokeInst *CreateGCStatepointInvoke(
>>   ^
>> /home/jenkins/test/llvm-project/llvm/tools/gollvm/passes/GoStatepoints.cpp:1570:52:
>> error: no member named 'getRetAttrs' in 'llvm::AttributeList'
>>  Call->getAttributes().getRetAttrs()));
>>  ~ ^
>> /home/jenkins/test/llvm-project/llvm/tools/gollvm/passes/GoStatepoints.cpp:1999:15:
>> error: no matching constructor for initialization of 'llvm::AttrBuilder'
>>   AttrBuilder R(Ctx);
>>   ^ ~~~
>> /home/jenkins/test/llvm-project/llvm/include/llvm/IR/Attributes.h:814:7:
>> note: candidate constructor (the implicit copy constructor) not viable: no
>> known conversion from 'llvm::LLVMContext' to 'const llvm::AttrBuilder' for
>> 1st argument
>> class AttrBuilder {
>>   ^
>> /home/jenkins/test/llvm-project/llvm/include/llvm/IR/Attributes.h:814:7:
>> note: candidate constructor (the implicit move constructor) not 

Re: [go-nuts] [gollvm] build fail

['Than McIntosh' via golang-nuts]

Hi,

Thanks for your interest in Gollvm.

The gollvm build is broken at tip at the moment;  due to competing demands
on my time, I haven't been able to work on this problem. Your patience is
abbreviated.

For now I suggest building with slightly older versions of the LLVM and
related repos. For example, this should work:

gollvm commit:  0e34e09fc15cde73f1b9974f2a657360abb94b4f
libbacktrace commit:  2446c66076480ce07a6bd868badcbceb3eeecc2e
libffi commit:  ab1677106605aba1c27665964ff90bea59612ce3
gofrontend commit 7f33baa09a8172bb2c5f1ca0435d9efe3e194c9b
llvm-project commit 0ac213667df1afbba3f66cb4fc3ec51073b9c158

Thanks, Than


On Mon, May 16, 2022 at 9:41 AM Honlim Chan  wrote:

> clang version 10.0.0-4ubuntu1
> build commands: cmake -DCMAKE_C_COMPILER=clang
> -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_INSTALL_PREFIX=/compiler/gollvm
> -DCMAKE_BUILD_TYPE=Release -DLLVM_USE_LINKER=gold -G Ninja
> ../llvm-project/llvm
> ninja gollvm
>
> [2184/3879] Building CXX object
> tools/gollvm/passes/CMakeFiles/LLVMCppGoPasses.dir/GoStatepoints.cpp.o
> FAILED:
> tools/gollvm/passes/CMakeFiles/LLVMCppGoPasses.dir/GoStatepoints.cpp.o
> /usr/bin/clang++ -DGTEST_HAS_RTTI=0 -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS
> -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
> -I/home/jenkins/test/build.rel/tools/gollvm/passes
> -I/home/jenkins/test/llvm-project/llvm/tools/gollvm/passes
> -I/home/jenkins/test/build.rel/include
> -I/home/jenkins/test/llvm-project/llvm/include -fPIC
> -fvisibility-inlines-hidden -Werror=date-time
> -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter
> -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic
> -Wno-long-long -Wc++98-compat-extra-semi -Wimplicit-fallthrough
> -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor
> -Wdelete-non-virtual-dtor -Wstring-conversion -Wmisleading-indentation
> -fdiagnostics-color -ffunction-sections -fdata-sections -O3 -DNDEBUG
>  -fno-exceptions -fno-rtti -std=c++14 -MD -MT
> tools/gollvm/passes/CMakeFiles/LLVMCppGoPasses.dir/GoStatepoints.cpp.o -MF
> tools/gollvm/passes/CMakeFiles/LLVMCppGoPasses.dir/GoStatepoints.cpp.o.d -o
> tools/gollvm/passes/CMakeFiles/LLVMCppGoPasses.dir/GoStatepoints.cpp.o -c
> /home/jenkins/test/llvm-project/llvm/tools/gollvm/passes/GoStatepoints.cpp
> /home/jenkins/test/llvm-project/llvm/tools/gollvm/passes/GoStatepoints.cpp:1286:31:
> error: no member named 'getFnAttrs' in 'llvm::AttributeList'
>   AttrBuilder FnAttrs(Ctx, AL.getFnAttrs());
>~~ ^
> /home/jenkins/test/llvm-project/llvm/tools/gollvm/passes/GoStatepoints.cpp:1290:25:
> error: no member named 'getFnAttrs' in 'llvm::AttributeList'
>   for (Attribute A : AL.getFnAttrs()) {
>  ~~ ^
> /home/jenkins/test/llvm-project/llvm/tools/gollvm/passes/GoStatepoints.cpp:1516:34:
> error: no matching member function for call to 'CreateGCStatepointInvoke'
> InvokeInst *Invoke = Builder.CreateGCStatepointInvoke(
>  ^~~~
> /home/jenkins/test/llvm-project/llvm/include/llvm/IR/IRBuilder.h:836:3:
> note: candidate function not viable: no known conversion from
> 'llvm::FunctionCallee' to 'llvm::Value *' for 3rd argument
>   CreateGCStatepointInvoke(uint64_t ID, uint32_t NumPatchBytes,
>   ^
> /home/jenkins/test/llvm-project/llvm/include/llvm/IR/IRBuilder.h:817:3:
> note: candidate function not viable: no known conversion from
> 'llvm::FunctionCallee' to 'llvm::Value *' for 3rd argument
>   CreateGCStatepointInvoke(uint64_t ID, uint32_t NumPatchBytes,
>   ^
> /home/jenkins/test/llvm-project/llvm/include/llvm/IR/IRBuilder.h:825:15:
> note: candidate function not viable: requires at least 10 arguments, but 9
> were provided
>   InvokeInst *CreateGCStatepointInvoke(
>   ^
> /home/jenkins/test/llvm-project/llvm/tools/gollvm/passes/GoStatepoints.cpp:1570:52:
> error: no member named 'getRetAttrs' in 'llvm::AttributeList'
>  Call->getAttributes().getRetAttrs()));
>  ~ ^
> /home/jenkins/test/llvm-project/llvm/tools/gollvm/passes/GoStatepoints.cpp:1999:15:
> error: no matching constructor for initialization of 'llvm::AttrBuilder'
>   AttrBuilder R(Ctx);
>   ^ ~~~
> /home/jenkins/test/llvm-project/llvm/include/llvm/IR/Attributes.h:814:7:
> note: candidate constructor (the implicit copy constructor) not viable: no
> known conversion from 'llvm::LLVMContext' to 'const llvm::AttrBuilder' for
> 1st argument
> class AttrBuilder {
>   ^
> /home/jenkins/test/llvm-project/llvm/include/llvm/IR/Attributes.h:814:7:
> note: candidate constructor (the implicit move constructor) not viable: no
> known conversion from 'llvm::LLVMContext' to 'llvm::AttrBuilder' for 1st
> argument
> /home/jenkins/test/llvm-project/llvm/include/llvm/IR/Attributes.h:830:3:
> note: candidate constructor not viable: no known conversion from
> 'llvm::LLVMContext' to 'const llvm::Attribute' for 1st argument
>   

Re: [go-nuts] [gollvm] Test for GoLLVM?

['Than McIntosh' via golang-nuts]

>Any ideas about running the tests under go/test directory

Yes, as you surmise it would be mainly about developing the appropriate
test harness. We haven't done anything in that direction for gollvm, but it
seems doable overall.

Than


On Tue, Apr 12, 2022 at 3:20 AM Lanzhiguan Huang 
wrote:

> Hello,
>   Any ideas about running the tests under go/test
>  directory? I think the test framework is
> designed to be applicable for all the go compilers(go, gccgo, gollvm...)
> but it seems there is something like assembly or unrecognizable flags which
> will block the test. Is there an easy way to filter out these unsupported
> things and run the test using gollvm?
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/33fe1b02-b9d5-4b46-95c2-42b96b04bd02n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BUr55Fg7_VmaARG5qxkWYwQN-Ahg1QUOJRiR_w6v54yzdH6Hg%40mail.gmail.com.

Re: [go-nuts] Dynamically loading custom passes with gollvm?

['Than McIntosh' via golang-nuts]

It would not be too hard to add this though. Want to send a patch?

>>Ohh! Yes please, that'll be very helpful for our experiments.
>>Thank you so much.

I think you misunderstood my comment. I was asking if you would like to
send a patch yourself.

Thanks, Than



On Mon, Apr 11, 2022 at 10:02 PM Balamurugan M  wrote:

> Hi!
>
> Ohh! Yes please, that'll be very helpful for our experiments.
> Thank you so much.
>
> Regards
>
> On Mon, Apr 11, 2022, 2:50 PM Than McIntosh  wrote:
>
>> Hello,
>>
>> At the moment gollvm doesn't support anything like the "-Xclang -load
>> -Xclang ...".
>>
>> It would not be too hard to add this though. Want to send a patch?
>>
>> Thanks, Than
>>
>>
>> On Sun, Apr 10, 2022 at 3:47 PM Balamurugan Marimuthu <
>> balamu...@gmail.com> wrote:
>>
>>> Yes, something like that! I basically want to run my custom pass as I
>>> compile using 'go build'
>>>
>>>  But looks like llvm-goc doesn't support the -Xclang option
>>>
>>>
>>>
>>>
>>> *$ go build -gccgoflags="-Xclang -load -Xclang
>>> ../passes/FunctionInsertPass.so" cache_main.go#
>>> command-line-arguments/gollvm/install/bin/llvm-goc: error: unrecognized
>>> command line option '-Xclang'/gollvm/install/bin/llvm-goc: error:
>>> unrecognized command line option '-Xclang'*
>>>
>>> Is there a way to load my custom pass as part of 'go build'?
>>>
>>> Thanks!
>>>
>>> On Sunday, April 10, 2022 at 12:14:34 AM UTC-4 Ian Lance Taylor wrote:
>>>
 On Sat, Apr 9, 2022 at 8:28 PM Balamurugan Marimuthu
  wrote:
 >
 > I see I can invoke the following and see the steps 'go build' is
 doing.
 >
 > % go build -work -x mypackage.go 1> transcript.txt 2>&1
 >
 > I struggle to understand how can I load my custom pass created as a
 shared library?
 >
 > I was looking for something like this which is done with Clang:
 > clang -Xclang -load -Xclang build/skeleton/libSkeletonPass.*
 something.c
 >
 > Is my understanding correct? Any help/pointers will be really
 helpful.

 Perhaps you are looking for something like

 go build -gccgoflags="-Xclang -load -Xclang
 build/skeleton/libSkeletonPass.*"

 Ian

>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to golang-nuts+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/9a976aca-4c5d-4074-a19d-f843e8b5ca63n%40googlegroups.com
>>> 
>>> .
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BUr55Gj_fqqKFM9CMSz%3DPS8V7gGrAfriaJBxVGtD-9jVThatA%40mail.gmail.com.

Re: [go-nuts] Dynamically loading custom passes with gollvm?

['Than McIntosh' via golang-nuts]

Hello,

At the moment gollvm doesn't support anything like the "-Xclang -load
-Xclang ...".

It would not be too hard to add this though. Want to send a patch?

Thanks, Than


On Sun, Apr 10, 2022 at 3:47 PM Balamurugan Marimuthu 
wrote:

> Yes, something like that! I basically want to run my custom pass as I
> compile using 'go build'
>
>  But looks like llvm-goc doesn't support the -Xclang option
>
>
>
>
> *$ go build -gccgoflags="-Xclang -load -Xclang
> ../passes/FunctionInsertPass.so" cache_main.go#
> command-line-arguments/gollvm/install/bin/llvm-goc: error: unrecognized
> command line option '-Xclang'/gollvm/install/bin/llvm-goc: error:
> unrecognized command line option '-Xclang'*
>
> Is there a way to load my custom pass as part of 'go build'?
>
> Thanks!
>
> On Sunday, April 10, 2022 at 12:14:34 AM UTC-4 Ian Lance Taylor wrote:
>
>> On Sat, Apr 9, 2022 at 8:28 PM Balamurugan Marimuthu
>>  wrote:
>> >
>> > I see I can invoke the following and see the steps 'go build' is doing.
>> >
>> > % go build -work -x mypackage.go 1> transcript.txt 2>&1
>> >
>> > I struggle to understand how can I load my custom pass created as a
>> shared library?
>> >
>> > I was looking for something like this which is done with Clang:
>> > clang -Xclang -load -Xclang build/skeleton/libSkeletonPass.*
>> something.c
>> >
>> > Is my understanding correct? Any help/pointers will be really helpful.
>>
>> Perhaps you are looking for something like
>>
>> go build -gccgoflags="-Xclang -load -Xclang
>> build/skeleton/libSkeletonPass.*"
>>
>> Ian
>>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/9a976aca-4c5d-4074-a19d-f843e8b5ca63n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BUr55FHKv3K0rm1S-58Om06_54aj4ZKS8G-nBkgKHVMh6ozrQ%40mail.gmail.com.

Re: [go-nuts] gollvm build failed

['Than McIntosh' via golang-nuts]

Hello,

Normally the definition of __morestack is drawn from libgcc.a, so I would
look to see what the story is with libgcc.a on your system.

Here are some things to try:

// Ask clang where it's picking up libgcc.a
$ clang --print-libgcc-file-name
/usr/bin/../lib/gcc/x86_64-linux-gnu/11/libgcc.a
$

// Ask the linker to trace the symbol during linking
$ clang-11  himom.c -fsplit-stack -Wl,-y,__morestack
/usr/bin/ld: /tmp/himom-9cb8d3.o: reference to __morestack
/usr/bin/ld: /usr/bin/../lib/gcc/x86_64-linux-gnu/11/libgcc.a(morestack.o):
definition of __morestack
$

Thanks, Than


On Sat, Feb 26, 2022 at 2:57 AM T Odin  wrote:

> Hi Than,
>
> I see there is malloc.h present in that path.
> But, cmake throws one more error even before the mmap issue:
>
> *-- Performing Test SPLIT_STACK_FUNCTIONAL*
> *-- Performing Test SPLIT_STACK_FUNCTIONAL - Failed*
> *-- trying -fcf-protection=none workaround*
> *-- Performing Test SPLIT_STACK_WORKAROUND*
> *-- Performing Test SPLIT_STACK_WORKAROUND - Failed*
> *CMake Error at tools/gollvm/cmake/modules/AddGollvm.cmake:68 (message):*
> *  C compiler does not support -fsplit-stack*
> *Call Stack (most recent call first):*
> *  tools/gollvm/CMakeLists.txt:22 (include)*
>
> Tried compiling the compile source specified in cmake file manually with
> fsplit-stack and workaround of fcf-protection=none.
> But, linker is unable to find the symbol __morestack:
>
>
> *ld: error: undefined symbol: __morestack*
>
> Can you please help if I'm missing out any configuration ?
>
> Build environment:
> clang 13.0.1 on FreeBSD 12.
>
> On Thursday, 27 January 2022 at 19:15:44 UTC+5:30 th...@google.com wrote:
>
>> Hello,
>>
>> As I understand it FreeBSD doesn't have any concept of a build essentials
>> package, so in theory /usr/include/malloc.h should always be installed. Are
>> you saying that this file doesn't exist on your system?
>>
>> Thanks, Than
>>
>>
>> On Thu, Jan 27, 2022 at 5:38 AM T Odin  wrote:
>>
>>> I'm trying to build gollvm on FreeBSD 13 using the command as mentioned
>>> in gollvm source page.
>>>
>>> *cmake -DCMAKE_BUILD_TYPE=Debug -DLLVM_USE_LINKER=gold -G Ninja
>>> ../llvm-project/llvm *
>>>
>>> I observed that during configuration it fails for malloc
>>>
>>> *Looking for malloc/malloc.hLooking for malloc/malloc.h - not found*
>>>
>>> which ends up with subsequent build failures for all the dependencies
>>> libffi, libbacktrace with
>>>
>>>
>>>
>>> *Support for mmap() is required -- setup failed.Call Stack (most recent
>>> call first):tools/gollvm/libgo/CMakeLists.txt:49 (setup_libffi)*
>>>
>>> I read from the FAQs that support for OS other than Linux wasn't
>>> supported. I'd like to clarify the changes required to be ported for
>>> compiling and supporting on other OS.
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to golang-nuts...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/238a962f-b12e-4ccb-b2d6-0bbd91fb0040n%40googlegroups.com
>>> 
>>> .
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/76c04c1c-8e50-43b2-9e88-7378535028b3n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BUr55ErEZ2o4ZXf%3D%3DZZLD-6aUXGxyt%2BRCTcn2P4H1pZM1CZzA%40mail.gmail.com.

Re: [go-nuts] [gollvm]: Build failed: error: undefined reference to 'runtime_1internal_1syscall.setErrno'

['Than McIntosh' via golang-nuts]

OK, I have checked in a fix for this issue (gollvm
commit 9bc0905a2f6697eff106b159120030a0e81bd113).

Regards, Than


On Thu, Feb 24, 2022 at 10:35 AM Than McIntosh  wrote:

> Greetings,
>
> Thanks for reporting this problem. I'll send a patch shortly.
>
> Thanks, Than
>
>
> On Wed, Feb 23, 2022 at 8:54 AM Richiise Nugraha 
> wrote:
>
>> Hi, tried to build gollvm but encountered this error:
>>
>> libbacktrace commit: 2446c66076480ce07a6bd868badcbceb3eeecc2e
>> libffi commit: ab1677106605aba1c27665964ff90bea59612ce3
>> gollvm commit: 6cd24cbc9ce21c0e6c74551e356c9323f1b1afaf
>> gofrontend commit: aee8eddbfc3ef1b03353a060e79e7d668fb229e2
>> llvmorg commit: 09629215c272f09e3ebde6cc7eac9625d28910ff
>>
>> SHELL=/bin/bash cmake -DCMAKE_BUILD_TYPE=Release -DLLVM_USE_LINKER=gold
>> -G Ninja ~/Workdir/llvm-project/llvm
>>
>> [1/6] Building go program buildid
>> FAILED: tools/gollvm/gotools/buildid
>> /mnt/ramdisk/build/tools/gollvm/gotools/buildid
>> cd /mnt/ramdisk/build/tools/gollvm/gotools &&
>> /mnt/ramdisk/build/./bin/llvm-goc -o
>> /mnt/ramdisk/build/tools/gollvm/gotools/buildid buildid_.o -I
>> /mnt/ramdisk/build/tools/gollvm/libgo -L
>> /mnt/ramdisk/build/tools/gollvm/libgo
>> /mnt/ramdisk/build/tools/gollvm/libgo/libgotool.a
>> /mnt/ramdisk/build/tools/gollvm/libgo/libgo.so: error: undefined
>> reference to 'runtime_1internal_1syscall.setErrno'
>> /mnt/ramdisk/build/tools/gollvm/libgo/libgo.so: error: undefined
>> reference to 'runtime_1internal_1syscall.getErrno'
>> [2/6] Building go program cgo
>> FAILED: tools/gollvm/gotools/cgo
>> /mnt/ramdisk/build/tools/gollvm/gotools/cgo
>> cd /mnt/ramdisk/build/tools/gollvm/gotools &&
>> /mnt/ramdisk/build/./bin/llvm-goc -o
>> /mnt/ramdisk/build/tools/gollvm/gotools/cgo cgo_.o -I
>> /mnt/ramdisk/build/tools/gollvm/libgo -L
>> /mnt/ramdisk/build/tools/gollvm/libgo
>> /mnt/ramdisk/build/tools/gollvm/libgo/libgotool.a
>> /mnt/ramdisk/build/tools/gollvm/libgo/libgo.so: error: undefined
>> reference to 'runtime_1internal_1syscall.setErrno'
>> /mnt/ramdisk/build/tools/gollvm/libgo/libgo.so: error: undefined
>> reference to 'runtime_1internal_1syscall.getErrno'
>> [3/6] Building go program test2json
>> FAILED: tools/gollvm/gotools/test2json
>> /mnt/ramdisk/build/tools/gollvm/gotools/test2json
>> cd /mnt/ramdisk/build/tools/gollvm/gotools &&
>> /mnt/ramdisk/build/./bin/llvm-goc -o
>> /mnt/ramdisk/build/tools/gollvm/gotools/test2json test2json_.o -I
>> /mnt/ramdisk/build/tools/gollvm/libgo -L
>> /mnt/ramdisk/build/tools/gollvm/libgo
>> /mnt/ramdisk/build/tools/gollvm/libgo/libgotool.a
>> /mnt/ramdisk/build/tools/gollvm/libgo/libgo.so: error: undefined
>> reference to 'runtime_1internal_1syscall.setErrno'
>> /mnt/ramdisk/build/tools/gollvm/libgo/libgo.so: error: undefined
>> reference to 'runtime_1internal_1syscall.getErrno'
>> [4/6] Building go program gofmt
>> FAILED: tools/gollvm/gotools/gofmt
>> /mnt/ramdisk/build/tools/gollvm/gotools/gofmt
>> cd /mnt/ramdisk/build/tools/gollvm/gotools &&
>> /mnt/ramdisk/build/./bin/llvm-goc -o
>> /mnt/ramdisk/build/tools/gollvm/gotools/gofmt gofmt_.o -I
>> /mnt/ramdisk/build/tools/gollvm/libgo -L
>> /mnt/ramdisk/build/tools/gollvm/libgo
>> /mnt/ramdisk/build/tools/gollvm/libgo/libgotool.a
>> /mnt/ramdisk/build/tools/gollvm/libgo/libgo.so: error: undefined
>> reference to 'runtime_1internal_1syscall.setErrno'
>> /mnt/ramdisk/build/tools/gollvm/libgo/libgo.so: error: undefined
>> reference to 'runtime_1internal_1syscall.getErrno'
>> [5/6] Building go program vet
>> FAILED: tools/gollvm/gotools/vet
>> /mnt/ramdisk/build/tools/gollvm/gotools/vet
>> cd /mnt/ramdisk/build/tools/gollvm/gotools &&
>> /mnt/ramdisk/build/./bin/llvm-goc -o
>> /mnt/ramdisk/build/tools/gollvm/gotools/vet vet_.o -I
>> /mnt/ramdisk/build/tools/gollvm/libgo -L
>> /mnt/ramdisk/build/tools/gollvm/libgo
>> /mnt/ramdisk/build/tools/gollvm/libgo/libgotool.a
>> /mnt/ramdisk/build/tools/gollvm/libgo/libgo.so: error: undefined
>> reference to 'runtime_1internal_1syscall.setErrno'
>> /mnt/ramdisk/build/tools/gollvm/libgo/libgo.so: error: undefined
>> reference to 'runtime_1internal_1syscall.getErrno'
>> [6/6] Building go program go
>> FAILED: tools/gollvm/gotools/go /mnt/ramdisk/build/tools/gollvm/gotools/go
>> cd /mnt/ramdisk/build/tools/gollvm/gotools &&
>> /mnt/ramdisk/build/./bin/llvm-goc -o
>> /mnt/ramdisk/build/tools/gollvm/gotools/go go_.o -I
>> /mnt/ramdisk/build/tools/gollvm/libgo -L
>> /mnt/ramdisk/build/tools/gollvm/libgo
>> /mnt/ramdisk/build/tools/gollvm/libgo/libgotool.a
>> /mnt/ramdisk/build/tools/gollvm/libgo/libgo.so: error: undefined
>> reference to 'runtime_1internal_1syscall.setErrno'
>> /mnt/ramdisk/build/tools/gollvm/libgo/libgo.so: error: undefined
>> reference to 'runtime_1internal_1syscall.getErrno'
>> ninja: build stopped: subcommand failed.
>> > /mnt/ramdisk/build/./bin/llvm-goc -o
>> /mnt/ramdisk/build/tools/gollvm/gotools/buildid buildid_.o -I
>> /mnt/ramdisk/build/tools/gollvm/libgo -L
>> /mnt/ramdisk/build/tools/gollvm/libgo
>> 

Re: [go-nuts] [gollvm]: Build failed: error: undefined reference to 'runtime_1internal_1syscall.setErrno'

['Than McIntosh' via golang-nuts]

Greetings,

Thanks for reporting this problem. I'll send a patch shortly.

Thanks, Than


On Wed, Feb 23, 2022 at 8:54 AM Richiise Nugraha 
wrote:

> Hi, tried to build gollvm but encountered this error:
>
> libbacktrace commit: 2446c66076480ce07a6bd868badcbceb3eeecc2e
> libffi commit: ab1677106605aba1c27665964ff90bea59612ce3
> gollvm commit: 6cd24cbc9ce21c0e6c74551e356c9323f1b1afaf
> gofrontend commit: aee8eddbfc3ef1b03353a060e79e7d668fb229e2
> llvmorg commit: 09629215c272f09e3ebde6cc7eac9625d28910ff
>
> SHELL=/bin/bash cmake -DCMAKE_BUILD_TYPE=Release -DLLVM_USE_LINKER=gold -G
> Ninja ~/Workdir/llvm-project/llvm
>
> [1/6] Building go program buildid
> FAILED: tools/gollvm/gotools/buildid
> /mnt/ramdisk/build/tools/gollvm/gotools/buildid
> cd /mnt/ramdisk/build/tools/gollvm/gotools &&
> /mnt/ramdisk/build/./bin/llvm-goc -o
> /mnt/ramdisk/build/tools/gollvm/gotools/buildid buildid_.o -I
> /mnt/ramdisk/build/tools/gollvm/libgo -L
> /mnt/ramdisk/build/tools/gollvm/libgo
> /mnt/ramdisk/build/tools/gollvm/libgo/libgotool.a
> /mnt/ramdisk/build/tools/gollvm/libgo/libgo.so: error: undefined reference
> to 'runtime_1internal_1syscall.setErrno'
> /mnt/ramdisk/build/tools/gollvm/libgo/libgo.so: error: undefined reference
> to 'runtime_1internal_1syscall.getErrno'
> [2/6] Building go program cgo
> FAILED: tools/gollvm/gotools/cgo
> /mnt/ramdisk/build/tools/gollvm/gotools/cgo
> cd /mnt/ramdisk/build/tools/gollvm/gotools &&
> /mnt/ramdisk/build/./bin/llvm-goc -o
> /mnt/ramdisk/build/tools/gollvm/gotools/cgo cgo_.o -I
> /mnt/ramdisk/build/tools/gollvm/libgo -L
> /mnt/ramdisk/build/tools/gollvm/libgo
> /mnt/ramdisk/build/tools/gollvm/libgo/libgotool.a
> /mnt/ramdisk/build/tools/gollvm/libgo/libgo.so: error: undefined reference
> to 'runtime_1internal_1syscall.setErrno'
> /mnt/ramdisk/build/tools/gollvm/libgo/libgo.so: error: undefined reference
> to 'runtime_1internal_1syscall.getErrno'
> [3/6] Building go program test2json
> FAILED: tools/gollvm/gotools/test2json
> /mnt/ramdisk/build/tools/gollvm/gotools/test2json
> cd /mnt/ramdisk/build/tools/gollvm/gotools &&
> /mnt/ramdisk/build/./bin/llvm-goc -o
> /mnt/ramdisk/build/tools/gollvm/gotools/test2json test2json_.o -I
> /mnt/ramdisk/build/tools/gollvm/libgo -L
> /mnt/ramdisk/build/tools/gollvm/libgo
> /mnt/ramdisk/build/tools/gollvm/libgo/libgotool.a
> /mnt/ramdisk/build/tools/gollvm/libgo/libgo.so: error: undefined reference
> to 'runtime_1internal_1syscall.setErrno'
> /mnt/ramdisk/build/tools/gollvm/libgo/libgo.so: error: undefined reference
> to 'runtime_1internal_1syscall.getErrno'
> [4/6] Building go program gofmt
> FAILED: tools/gollvm/gotools/gofmt
> /mnt/ramdisk/build/tools/gollvm/gotools/gofmt
> cd /mnt/ramdisk/build/tools/gollvm/gotools &&
> /mnt/ramdisk/build/./bin/llvm-goc -o
> /mnt/ramdisk/build/tools/gollvm/gotools/gofmt gofmt_.o -I
> /mnt/ramdisk/build/tools/gollvm/libgo -L
> /mnt/ramdisk/build/tools/gollvm/libgo
> /mnt/ramdisk/build/tools/gollvm/libgo/libgotool.a
> /mnt/ramdisk/build/tools/gollvm/libgo/libgo.so: error: undefined reference
> to 'runtime_1internal_1syscall.setErrno'
> /mnt/ramdisk/build/tools/gollvm/libgo/libgo.so: error: undefined reference
> to 'runtime_1internal_1syscall.getErrno'
> [5/6] Building go program vet
> FAILED: tools/gollvm/gotools/vet
> /mnt/ramdisk/build/tools/gollvm/gotools/vet
> cd /mnt/ramdisk/build/tools/gollvm/gotools &&
> /mnt/ramdisk/build/./bin/llvm-goc -o
> /mnt/ramdisk/build/tools/gollvm/gotools/vet vet_.o -I
> /mnt/ramdisk/build/tools/gollvm/libgo -L
> /mnt/ramdisk/build/tools/gollvm/libgo
> /mnt/ramdisk/build/tools/gollvm/libgo/libgotool.a
> /mnt/ramdisk/build/tools/gollvm/libgo/libgo.so: error: undefined reference
> to 'runtime_1internal_1syscall.setErrno'
> /mnt/ramdisk/build/tools/gollvm/libgo/libgo.so: error: undefined reference
> to 'runtime_1internal_1syscall.getErrno'
> [6/6] Building go program go
> FAILED: tools/gollvm/gotools/go /mnt/ramdisk/build/tools/gollvm/gotools/go
> cd /mnt/ramdisk/build/tools/gollvm/gotools &&
> /mnt/ramdisk/build/./bin/llvm-goc -o
> /mnt/ramdisk/build/tools/gollvm/gotools/go go_.o -I
> /mnt/ramdisk/build/tools/gollvm/libgo -L
> /mnt/ramdisk/build/tools/gollvm/libgo
> /mnt/ramdisk/build/tools/gollvm/libgo/libgotool.a
> /mnt/ramdisk/build/tools/gollvm/libgo/libgo.so: error: undefined reference
> to 'runtime_1internal_1syscall.setErrno'
> /mnt/ramdisk/build/tools/gollvm/libgo/libgo.so: error: undefined reference
> to 'runtime_1internal_1syscall.getErrno'
> ninja: build stopped: subcommand failed.
> > /mnt/ramdisk/build/./bin/llvm-goc -o
> /mnt/ramdisk/build/tools/gollvm/gotools/buildid buildid_.o -I
> /mnt/ramdisk/build/tools/gollvm/libgo -L
> /mnt/ramdisk/build/tools/gollvm/libgo
> /mnt/ramdisk/build/tools/gollvm/libgo/libgotool.a
>
> /mnt/ramdisk/build/./bin/llvm-goc: error: input file 'buildid_.o' does not
> exist
> > cd /mnt/ramdisk/build/tools/gollvm/gotools &&
> /mnt/ramdisk/build/./bin/llvm-goc -o
> /mnt/ramdisk/build/tools/gollvm/gotools/buildid buildid_.o -I
> 

Re: [go-nuts] Re: gollvm compilation issue

['Than McIntosh' via golang-nuts]

OK, I checked in another CL to resolve this new issue. Give it a try again
please and let me know if you are able to build.

Thanks, Than


On Wed, Feb 9, 2022 at 2:35 PM Than McIntosh  wrote:

> Thanks for the report. I'll take a look...
>
> Than
>
> On Wed, Feb 9, 2022 at 2:33 PM Zhen Huang 
> wrote:
>
>> Thank you for the prompt response! I checked out the updated code and the
>> previous compilation error is gone. However, another compilation error came
>> up:
>>
>> [183/1626] Building CXX object
>> tools/g...LVMCppGoPasses.dir/GoStatepoints.cpp.o
>> FAILED:
>> tools/gollvm/passes/CMakeFiles/LLVMCppGoPasses.dir/GoStatepoints.cpp.o
>> /usr/bin/c++  -DGTEST_HAS_RTTI=0 -D_DEBUG -D_GNU_SOURCE
>> -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
>> -Itools/gollvm/passes
>> -I/home/user/code/llvm/llvm-project/llvm/tools/gollvm/passes -Iinclude
>> -I/home/user/code/llvm/llvm-project/llvm/include -fPIC
>> -fno-semantic-interposition -fvisibility-inlines-hidden -Werror=date-time
>> -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual
>> -Wno-missing-field-initializers -pedantic -Wno-long-long
>> -Wimplicit-fallthrough -Wno-maybe-uninitialized -Wno-class-memaccess
>> -Wno-redundant-move -Wno-pessimizing-move -Wno-noexcept-type
>> -Wdelete-non-virtual-dtor -Wsuggest-override -Wno-comment
>> -Wmisleading-indentation -fdiagnostics-color -g-fno-exceptions
>> -fno-rtti -fcf-protection=none -std=c++14 -MD -MT
>> tools/gollvm/passes/CMakeFiles/LLVMCppGoPasses.dir/GoStatepoints.cpp.o -MF
>> tools/gollvm/passes/CMakeFiles/LLVMCppGoPasses.dir/GoStatepoints.cpp.o.d -o
>> tools/gollvm/passes/CMakeFiles/LLVMCppGoPasses.dir/GoStatepoints.cpp.o -c
>> /home/user/code/llvm/llvm-project/llvm/tools/gollvm/passes/GoStatepoints.cpp
>> /home/user/code/llvm/llvm-project/llvm/tools/gollvm/passes/GoStatepoints.cpp:
>> In function ‘void makeStatepointExplicitImpl(llvm::CallBase*,
>> llvm::SmallVectorImpl&, llvm::SmallVectorImpl&,
>> {anonymous}::PartiallyConstructedSafepointRecord&,
>> std::vector<{anonymous}::DeferredReplacement>&)’:
>> /home/user/code/llvm/llvm-project/llvm/tools/gollvm/passes/GoStatepoints.cpp:1433:65:
>> warning: ‘llvm::Type* llvm::PointerType::getElementType() const’ is
>> deprecated: Pointer element types are deprecated. You can *temporarily* use
>> Type::getPointerElementType() instead [-Wdeprecated-declarations]
>>  1433 |   Type *T = cast(V->getType())->getElementType();
>>   | ^
>> In file included from
>> /home/user/code/llvm/llvm-project/llvm/include/llvm/IR/Function.h:29,
>>  from
>> /home/user/code/llvm/llvm-project/llvm/include/llvm/IR/PassManager.h:45,
>>  from
>> /home/user/code/llvm/llvm-project/llvm/tools/gollvm/passes/GoStatepoints.h:20,
>>  from
>> /home/user/code/llvm/llvm-project/llvm/tools/gollvm/passes/GoStatepoints.cpp:15:
>> /home/user/code/llvm/llvm-project/llvm/include/llvm/IR/DerivedTypes.h:675:9:
>> note: declared here
>>   675 |   Type *getElementType() const {
>>   | ^~
>> /home/user/code/llvm/llvm-project/llvm/tools/gollvm/passes/GoStatepoints.cpp:1517:27:
>> error: no matching function for call to
>> ‘llvm::IRBuilder<>::CreateGCStatepointInvoke(uint64_t&, uint32_t&,
>> llvm::Value*&, llvm::BasicBlock*, llvm::BasicBlock*,
>> llvm::ArrayRef&, llvm::ArrayRef&,
>> llvm::ArrayRef, const char [17])’
>>  1517 | "statepoint_token");
>>   |   ^
>> In file included from
>> /home/user/code/llvm/llvm-project/llvm/tools/gollvm/passes/GoStatepoints.cpp:45:
>> /home/user/code/llvm/llvm-project/llvm/include/llvm/IR/IRBuilder.h:809:3:
>> note: candidate: ‘llvm::InvokeInst*
>> llvm::IRBuilderBase::CreateGCStatepointInvoke(uint64_t, uint32_t,
>> llvm::FunctionCallee, llvm::BasicBlock*, llvm::BasicBlock*,
>> llvm::ArrayRef, llvm::Optional
>> >, llvm::ArrayRef, const llvm::Twine&)’
>>   809 |   CreateGCStatepointInvoke(uint64_t ID, uint32_t NumPatchBytes,
>>   |   ^~~~
>> /home/user/code/llvm/llvm-project/llvm/include/llvm/IR/IRBuilder.h:810:43:
>> note:   no known conversion for argument 3 from ‘llvm::Value*’ to
>> ‘llvm::FunctionCallee’
>>   810 |FunctionCallee ActualInvokee,
>> BasicBlock *NormalDest,
>>   |~~~^
>> /home/user/code/llvm/llvm-project/llvm/include/llvm/IR/IRBuilder.h:817:15:
>> note: candidate: ‘llvm::InvokeInst*
>> llvm::IRBuilderBase::CreateGCStatepointInvoke(uint64_t, uint32_t,
>> llvm::FunctionCallee, llvm::BasicBlock*, llvm::BasicBlock*, uint32_t,
>> llvm::ArrayRef, llvm::Optional >,
>> llvm::Optional >, llvm::ArrayRef,
>> const llvm::Twine&)’
>>   817 |   InvokeInst *CreateGCStatepointInvoke(
>>   |   ^~~~
>> /home/user/code/llvm/llvm-project/llvm/include/llvm/IR/IRBuilder.h:817:15:
>> note:   candidate expects 11 arguments, 9 

Re: [go-nuts] Re: gollvm compilation issue

['Than McIntosh' via golang-nuts]

Thanks for the report. I'll take a look...

Than

On Wed, Feb 9, 2022 at 2:33 PM Zhen Huang  wrote:

> Thank you for the prompt response! I checked out the updated code and the
> previous compilation error is gone. However, another compilation error came
> up:
>
> [183/1626] Building CXX object
> tools/g...LVMCppGoPasses.dir/GoStatepoints.cpp.o
> FAILED:
> tools/gollvm/passes/CMakeFiles/LLVMCppGoPasses.dir/GoStatepoints.cpp.o
> /usr/bin/c++  -DGTEST_HAS_RTTI=0 -D_DEBUG -D_GNU_SOURCE
> -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
> -Itools/gollvm/passes
> -I/home/user/code/llvm/llvm-project/llvm/tools/gollvm/passes -Iinclude
> -I/home/user/code/llvm/llvm-project/llvm/include -fPIC
> -fno-semantic-interposition -fvisibility-inlines-hidden -Werror=date-time
> -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual
> -Wno-missing-field-initializers -pedantic -Wno-long-long
> -Wimplicit-fallthrough -Wno-maybe-uninitialized -Wno-class-memaccess
> -Wno-redundant-move -Wno-pessimizing-move -Wno-noexcept-type
> -Wdelete-non-virtual-dtor -Wsuggest-override -Wno-comment
> -Wmisleading-indentation -fdiagnostics-color -g-fno-exceptions
> -fno-rtti -fcf-protection=none -std=c++14 -MD -MT
> tools/gollvm/passes/CMakeFiles/LLVMCppGoPasses.dir/GoStatepoints.cpp.o -MF
> tools/gollvm/passes/CMakeFiles/LLVMCppGoPasses.dir/GoStatepoints.cpp.o.d -o
> tools/gollvm/passes/CMakeFiles/LLVMCppGoPasses.dir/GoStatepoints.cpp.o -c
> /home/user/code/llvm/llvm-project/llvm/tools/gollvm/passes/GoStatepoints.cpp
> /home/user/code/llvm/llvm-project/llvm/tools/gollvm/passes/GoStatepoints.cpp:
> In function ‘void makeStatepointExplicitImpl(llvm::CallBase*,
> llvm::SmallVectorImpl&, llvm::SmallVectorImpl&,
> {anonymous}::PartiallyConstructedSafepointRecord&,
> std::vector<{anonymous}::DeferredReplacement>&)’:
> /home/user/code/llvm/llvm-project/llvm/tools/gollvm/passes/GoStatepoints.cpp:1433:65:
> warning: ‘llvm::Type* llvm::PointerType::getElementType() const’ is
> deprecated: Pointer element types are deprecated. You can *temporarily* use
> Type::getPointerElementType() instead [-Wdeprecated-declarations]
>  1433 |   Type *T = cast(V->getType())->getElementType();
>   | ^
> In file included from
> /home/user/code/llvm/llvm-project/llvm/include/llvm/IR/Function.h:29,
>  from
> /home/user/code/llvm/llvm-project/llvm/include/llvm/IR/PassManager.h:45,
>  from
> /home/user/code/llvm/llvm-project/llvm/tools/gollvm/passes/GoStatepoints.h:20,
>  from
> /home/user/code/llvm/llvm-project/llvm/tools/gollvm/passes/GoStatepoints.cpp:15:
> /home/user/code/llvm/llvm-project/llvm/include/llvm/IR/DerivedTypes.h:675:9:
> note: declared here
>   675 |   Type *getElementType() const {
>   | ^~
> /home/user/code/llvm/llvm-project/llvm/tools/gollvm/passes/GoStatepoints.cpp:1517:27:
> error: no matching function for call to
> ‘llvm::IRBuilder<>::CreateGCStatepointInvoke(uint64_t&, uint32_t&,
> llvm::Value*&, llvm::BasicBlock*, llvm::BasicBlock*,
> llvm::ArrayRef&, llvm::ArrayRef&,
> llvm::ArrayRef, const char [17])’
>  1517 | "statepoint_token");
>   |   ^
> In file included from
> /home/user/code/llvm/llvm-project/llvm/tools/gollvm/passes/GoStatepoints.cpp:45:
> /home/user/code/llvm/llvm-project/llvm/include/llvm/IR/IRBuilder.h:809:3:
> note: candidate: ‘llvm::InvokeInst*
> llvm::IRBuilderBase::CreateGCStatepointInvoke(uint64_t, uint32_t,
> llvm::FunctionCallee, llvm::BasicBlock*, llvm::BasicBlock*,
> llvm::ArrayRef, llvm::Optional
> >, llvm::ArrayRef, const llvm::Twine&)’
>   809 |   CreateGCStatepointInvoke(uint64_t ID, uint32_t NumPatchBytes,
>   |   ^~~~
> /home/user/code/llvm/llvm-project/llvm/include/llvm/IR/IRBuilder.h:810:43:
> note:   no known conversion for argument 3 from ‘llvm::Value*’ to
> ‘llvm::FunctionCallee’
>   810 |FunctionCallee ActualInvokee,
> BasicBlock *NormalDest,
>   |~~~^
> /home/user/code/llvm/llvm-project/llvm/include/llvm/IR/IRBuilder.h:817:15:
> note: candidate: ‘llvm::InvokeInst*
> llvm::IRBuilderBase::CreateGCStatepointInvoke(uint64_t, uint32_t,
> llvm::FunctionCallee, llvm::BasicBlock*, llvm::BasicBlock*, uint32_t,
> llvm::ArrayRef, llvm::Optional >,
> llvm::Optional >, llvm::ArrayRef,
> const llvm::Twine&)’
>   817 |   InvokeInst *CreateGCStatepointInvoke(
>   |   ^~~~
> /home/user/code/llvm/llvm-project/llvm/include/llvm/IR/IRBuilder.h:817:15:
> note:   candidate expects 11 arguments, 9 provided
> /home/user/code/llvm/llvm-project/llvm/include/llvm/IR/IRBuilder.h:828:3:
> note: candidate: ‘llvm::InvokeInst*
> llvm::IRBuilderBase::CreateGCStatepointInvoke(uint64_t, uint32_t,
> llvm::FunctionCallee, llvm::BasicBlock*, llvm::BasicBlock*,
> llvm::ArrayRef, llvm::Optional >,
> 

Re: [go-nuts] decoding DWARF data

['Than McIntosh' via golang-nuts]

For general information on DWARF and inlining, you might look at this
design doc:

https://github.com/golang/proposal/blob/master/design/22080-dwarf-inlining.md#example

which describes the changes made to the compiler to add DWARF inlining
support. HTH.

Thanks, Than


On Sat, Feb 5, 2022 at 4:44 AM stephen.t@gmail.com <
stephen.t.illingwo...@gmail.com> wrote:

>
> (This is possibly off-topic)
>
> I'm trying to decode the DWARF data in an ELF binary and I'm not sure how
> to handle functions.
>
> I'm using the elf/dwarf package in the Go standard library and
> successfully using it to identify compile units and source files and also
> to find line entries for an executed address.
>
> What I can't see is how to relate a dwarf.LineEntry to a function (or
> SubProgram as it is called in DWARF terminology).
>
> If the SubProgram TAG has both Low PC and High PC attributes then I can
> see how it can be done. Where it gets tricky is if a SubProgram has been
> inlined.
>
> What I don't fully understand is how InlinedSubPrograms relate to
> SubPrograms.
>
> I realise that this isn't really a Go question but I'm hoping someone has
> used the Go standard library in this way and understands how to solve this
> problem.
>
> Thanks.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/6b1b4e4f-e9af-4954-9296-de50b4d548f5n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BUr55Gisy%2BawokwUULiv10hcdeVOD%3DuUD-WXMDwo0raMX5fZg%40mail.gmail.com.

Re: [go-nuts] gollvm build failed

['Than McIntosh' via golang-nuts]

Hello,

As I understand it FreeBSD doesn't have any concept of a build essentials
package, so in theory /usr/include/malloc.h should always be installed. Are
you saying that this file doesn't exist on your system?

Thanks, Than


On Thu, Jan 27, 2022 at 5:38 AM T Odin  wrote:

> I'm trying to build gollvm on FreeBSD 13 using the command as mentioned in
> gollvm source page.
>
> *cmake -DCMAKE_BUILD_TYPE=Debug -DLLVM_USE_LINKER=gold -G Ninja
> ../llvm-project/llvm *
>
> I observed that during configuration it fails for malloc
>
> *Looking for malloc/malloc.hLooking for malloc/malloc.h - not found*
>
> which ends up with subsequent build failures for all the dependencies
> libffi, libbacktrace with
>
>
>
> *Support for mmap() is required -- setup failed.Call Stack (most recent
> call first):tools/gollvm/libgo/CMakeLists.txt:49 (setup_libffi)*
>
> I read from the FAQs that support for OS other than Linux wasn't
> supported. I'd like to clarify the changes required to be ported for
> compiling and supporting on other OS.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/238a962f-b12e-4ccb-b2d6-0bbd91fb0040n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BUr55E%3DhMwLXZuLRdjBZ%2BC-sn%3Drx3jx0wOUHVTJoDuFHxPk1g%40mail.gmail.com.

Re: [go-nuts] Help with GOLLVM

['Than McIntosh' via golang-nuts]

Hi,

>>The whole point of my poc was to be able to get the LLVMIR of GO then put
it into an iOS app with bitcode enable. What are you saying is that it is
not possible to achieve this?

It's definitely outside the normal/expected use of gollvm, but it seems at
least possible to do this.

The key thing is that for a Go program to run, it needs copies of all its
dependent packages. That means that those packages need to be compiled down
to bitcode as well, and then the whole collection handed off to whatever is
going to be executing the bitcode.

To list your transitive dependencies, you can do something like

  $ go list -json hello2.go

and then look at the "Deps" section.

I think the last time this was attempted, some hacks were required in the
runtime (see https://go-review.googlesource.com/c/gofrontend/+/140917), so
you might need to dust off that CL and get it working again.

Thanks, Than




On Tue, Jan 4, 2022 at 2:49 AM Danilo bestbug 
wrote:

> Hello,
> Thanks for the answer. I've still some question then. The whole point of
> my poc was to be able to get the LLVMIR of GO then put it into an iOS app
> with bitcode enable. What are you saying is that it is not possible to
> achieve this? Or it's possible but I've to add the missing symbols? If is
> the second thing do you have any idea how to do this?
>
> Thanks!
>
> Il giorno gio 16 dic 2021 alle ore 22:38 Than McIntosh 
> ha scritto:
>
>> Greetings,
>>
>> The code that Go compilers emit is closely tied to the Go runtime-- any
>> compiled Go code (including *.ll files) will have references to symbols
>> that it needs from the runtime. When you try to convert your LLVM-produced
>> bitcode into a binary via
>>
>> clang helloworld.ll -o helloworldLLVM
>>
>> you're effectively not including definitions of any of those key runtime
>> routines (for example, "runtime.newobject", which is one of the functions
>> that supports memory allocation).
>>
>> It would be similar to what might happen if you took a C++ "hi mom"
>> program, compiled it down to an object file using "clang++", then tried to
>> link the resulting object into a binary using "gcc".
>>
>> Hope this helps--
>>
>> Than
>>
>> On Thu, Dec 16, 2021 at 1:07 PM Danilo bestbug <
>> bestbug.corporat...@gmail.com> wrote:
>>
>>> Hello,
>>>
>>> I've create a docker images with ubuntu 20.10 with GOLLVM, I'm using at
>>> the moment a simple test repository
>>> , I was able to create
>>> the ll file with the following command:
>>>
>>> go build -gccgoflags -static-libgo -x -work 1> transcript.txt 2>&1
>>> WORK=$(egrep -m 1 '(WORK=|llvm-goc -c)' transcript.txt | awk '{ print
>>> substr ($0, 6 ) }')
>>>
>>> /gollvm/install/bin/llvm-goc -c -O2 -g -m64
>>> -fdebug-prefix-map=$WORK=/tmp/go-build \
>>> -gno-record-gcc-switches -fgo-pkgpath=$PWD \
>>> -fgo-relative-import-path=$PWD -o $WORK/b001/_go_.o \
>>> -I $WORK/b001/_importcfgroot_ -o $LLFILE -S -emit-llvm $MAINFILE
>>>
>>> But when I try to convert to binary via clang the file I've some error:
>>> clang helloworld.ll -o helloworldLLVM
>>> warning: overriding the module target triple with x86_64-pc-linux-gnu
>>> [-Woverride-module]
>>> 1 warning generated.
>>> /usr/bin/ld:
>>> /usr/bin/../lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu/crt1.o:
>>> in function `_start':
>>> (.text+0x24): undefined reference to `main'
>>> /usr/bin/ld: /tmp/helloworld-bcb8cc.o: in function
>>> `_..z2fopt..z2fvmsdk..z2fhelloworld.describe':
>>> /opt/vmsdk/helloworld/./describe.go:6: undefined reference to
>>> `runtime.newobject'
>>> /usr/bin/ld: /opt/vmsdk/helloworld/./describe.go:6: undefined reference
>>> to `runtime.writeBarrier'
>>> /usr/bin/ld: /opt/vmsdk/helloworld/./describe.go:6: undefined reference
>>> to `fmt.Printf'
>>> /usr/bin/ld: /opt/vmsdk/helloworld/./describe.go:6: undefined reference
>>> to `runtime.typedmemmove'
>>> /usr/bin/ld:
>>> /tmp/helloworld-bcb8cc.o:(.rodata.string..d[string..d]+0x18): undefined
>>> reference to `runtime.strequal..f'
>>> /usr/bin/ld:
>>> /tmp/helloworld-bcb8cc.o:(.rodata.type...1string[type...1string]+0x18):
>>> undefined reference to `runtime.memequal64..f'
>>> clang: error: linker command failed with exit code 1 (use -v to see
>>> invocation)
>>>
>>>
>>> I'm this is the first time I use this buildchain and I don't understand
>>> what I'm doing wrong. Can someone help me?
>>> Those are the commit I've used for build gollvm, if needed
>>>
>>> llvm-project: 43ff75f2c3feef64f9d73328230d34dac8832a91
>>> llvm-project/llvm/tools/gollvm: 44a7a475cfd3b871b7a5a0941b8ab1ea9d489adc
>>> llvm-project/llvm/tools/gollvm/gofrontend:
>>> be0d2cc2df9f98d967c242594838f86362dae2e7
>>> llvm-project/llvm/tools/gollvm/libgo/libffi:
>>> 737d4faa00d681b4c758057f67e1a02d813d01c2
>>> llvm-project/llvm/tools/gollvm/libgo/libbacktrace:
>>> 5a99ff7fed66b8ea8f09c9805c138524a7035ece
>>>
>>> Thanks in advance!
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups 

Re: [go-nuts] Help with GOLLVM

['Than McIntosh' via golang-nuts]

Greetings,

The code that Go compilers emit is closely tied to the Go runtime-- any
compiled Go code (including *.ll files) will have references to symbols
that it needs from the runtime. When you try to convert your LLVM-produced
bitcode into a binary via

clang helloworld.ll -o helloworldLLVM

you're effectively not including definitions of any of those key runtime
routines (for example, "runtime.newobject", which is one of the functions
that supports memory allocation).

It would be similar to what might happen if you took a C++ "hi mom"
program, compiled it down to an object file using "clang++", then tried to
link the resulting object into a binary using "gcc".

Hope this helps--

Than

On Thu, Dec 16, 2021 at 1:07 PM Danilo bestbug <
bestbug.corporat...@gmail.com> wrote:

> Hello,
>
> I've create a docker images with ubuntu 20.10 with GOLLVM, I'm using at
> the moment a simple test repository
> , I was able to create
> the ll file with the following command:
>
> go build -gccgoflags -static-libgo -x -work 1> transcript.txt 2>&1
> WORK=$(egrep -m 1 '(WORK=|llvm-goc -c)' transcript.txt | awk '{ print
> substr ($0, 6 ) }')
>
> /gollvm/install/bin/llvm-goc -c -O2 -g -m64
> -fdebug-prefix-map=$WORK=/tmp/go-build \
> -gno-record-gcc-switches -fgo-pkgpath=$PWD \
> -fgo-relative-import-path=$PWD -o $WORK/b001/_go_.o \
> -I $WORK/b001/_importcfgroot_ -o $LLFILE -S -emit-llvm $MAINFILE
>
> But when I try to convert to binary via clang the file I've some error:
> clang helloworld.ll -o helloworldLLVM
> warning: overriding the module target triple with x86_64-pc-linux-gnu
> [-Woverride-module]
> 1 warning generated.
> /usr/bin/ld:
> /usr/bin/../lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu/crt1.o:
> in function `_start':
> (.text+0x24): undefined reference to `main'
> /usr/bin/ld: /tmp/helloworld-bcb8cc.o: in function
> `_..z2fopt..z2fvmsdk..z2fhelloworld.describe':
> /opt/vmsdk/helloworld/./describe.go:6: undefined reference to
> `runtime.newobject'
> /usr/bin/ld: /opt/vmsdk/helloworld/./describe.go:6: undefined reference to
> `runtime.writeBarrier'
> /usr/bin/ld: /opt/vmsdk/helloworld/./describe.go:6: undefined reference to
> `fmt.Printf'
> /usr/bin/ld: /opt/vmsdk/helloworld/./describe.go:6: undefined reference to
> `runtime.typedmemmove'
> /usr/bin/ld: /tmp/helloworld-bcb8cc.o:(.rodata.string..d[string..d]+0x18):
> undefined reference to `runtime.strequal..f'
> /usr/bin/ld:
> /tmp/helloworld-bcb8cc.o:(.rodata.type...1string[type...1string]+0x18):
> undefined reference to `runtime.memequal64..f'
> clang: error: linker command failed with exit code 1 (use -v to see
> invocation)
>
>
> I'm this is the first time I use this buildchain and I don't understand
> what I'm doing wrong. Can someone help me?
> Those are the commit I've used for build gollvm, if needed
>
> llvm-project: 43ff75f2c3feef64f9d73328230d34dac8832a91
> llvm-project/llvm/tools/gollvm: 44a7a475cfd3b871b7a5a0941b8ab1ea9d489adc
> llvm-project/llvm/tools/gollvm/gofrontend:
> be0d2cc2df9f98d967c242594838f86362dae2e7
> llvm-project/llvm/tools/gollvm/libgo/libffi:
> 737d4faa00d681b4c758057f67e1a02d813d01c2
> llvm-project/llvm/tools/gollvm/libgo/libbacktrace:
> 5a99ff7fed66b8ea8f09c9805c138524a7035ece
>
> Thanks in advance!
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/d503d8bf-e904-42be-9955-6813d4f8c29fn%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BUr55EkHmiMhUXTWqWNY0bQOTzV6fkte-T5XieSWeQxnKJKsg%40mail.gmail.com.

Re: [go-nuts] Unable to build gollvm: missing and no known rule to make it

['Than McIntosh' via golang-nuts]

Hi,

Sorry for the misunderstanding--

When I said "from build area root" I am talking about the directory where
you are running "ninja", not the directory that contains the source code
for gollvm. Within your gollvm git repo, you will definitely still need the
"libgo" subdir.

So let's say that you have your LLVM repo checked out in

   /tmp/llvm-project

meaning that within this directory you would have

   /tmp/llvm-project/llvm/tools/gollvm
   /tmp/llvm-project/llvm/tools/gollvm/libgo
   /tmp/llvm-project/llvm/tools/gollvm/gofrontend
   ...

Then somewhere else you would have your build area, perhaps in /tmp/build.
Within that build area you first run cmake, then run ninja e.g.

  cd /tmp/build
  cmake  -G Ninja ../llvm-project/llvm
  ninja ...

What I am suggesting is that from your build area (/tmp/build, NOT
/tmp/llvm-project) you issue the command

  rm -rf tools/gollvm/libgo

Thanks, Than


On Mon, Nov 22, 2021 at 11:42 AM Pure White  wrote:

> Hi,
> the `libgo` under gollvm seems is a part of gollvm, and after I delete it
> there's another error:
> ```
> $ cmake -DCMAKE_BUILD_TYPE=Debug -DLLVM_USE_LINKER=gold -G Ninja
> ../llvm-project/llvm
> -- Native target architecture is X86
> -- Threads enabled.
> ...
> -- Targeting XCore
> -- default linker set to "gold"
> CMake Error at tools/gollvm/CMakeLists.txt:131 (add_subdirectory):
>   add_subdirectory given source "libgo" which is not an existing directory.
>
>
> -- starting gotools configuration.
> CMake Error at tools/gollvm/gotools/CMakeLists.txt:40 (mkzdefaultcc):
>   Unknown CMake command "mkzdefaultcc".
>
>
> -- Configuring incomplete, errors occurred!
> See also
> "/data00/home/purewhite/gollvm/build-debug/CMakeFiles/CMakeOutput.log".
> See also
> "/data00/home/purewhite/gollvm/build-debug/CMakeFiles/CMakeError.log".
> ```
>
> 在2021年11月23日星期二 UTC+8 上午12:02:38 写道：
>
>> Hi,
>>
>> I sometimes see that error when doing an incremental build of libgo after
>> something has changed in the go frontend repo. I suggest that in your build
>> directory you remove the libgo dir (e.g. from build area root "rm -rf
>>  tools/gollvm/libgo"), rerun cmake, and then try again.
>>
>> I did a test build just now with tip:
>>
>> LLVM: 56db1c072c92be36fb1d76aa30487ad62dc58ea8
>> gollvm: 263e415e02543b9d46d19b5076454ae6c07860fe
>> gofrontend: 3e9f4ee16683883ccfb8661d99318c74bb7a4bef
>>
>> and it seems to work ok.
>>
>> Thanks, Than
>>
>> On Sun, Nov 21, 2021 at 9:08 AM Pure White  wrote:
>>
>>> Hi,
>>> I'm trying to build gollvm, but encountered some problems.
>>> When executing `cmake -DCMAKE_BUILD_TYPE=Debug -DLLVM_USE_LINKER=gold -G
>>> Ninja ../llvm-project/llvm`, there's some error log:[image:
>>> screenshot-20211121-220213.png][image: screenshot-20211121-220227.png]
>>>
>>> After this, I run `ninja gollvm` and get the following:
>>> ```
>>> ninja: error:
>>> '/data00/home/purewhite/gollvm/llvm-project/llvm/tools/gollvm/gotools/buildid.go',
>>> needed by 'tools/gollvm/gotools/buildid', missing and no known rule to make
>>> it
>>> ```
>>> The commits of related projects are below:
>>> llvm-project: 3234f2d9c1669459833e717d34c10296d78b7818
>>> gollvm: f17ba8c7708356ef447525e05cd6f2770845c7d7
>>> gofrontend: 3e9f4ee16683883ccfb8661d99318c74bb7a4bef
>>> They are all the latest commits(at this time).
>>>
>>> Does anyone know how to deal with this? Or can anyone reproduce this
>>> error?
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to golang-nuts...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/0959a8a9-358f-4e46-b7d0-c5015bbd81c2n%40googlegroups.com
>>> 
>>> .
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/cdec48e9-3287-401a-b243-5021133c057bn%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BUr55H-gT%3DN-PJN-Z36ReGeF0mv9WLCMXXYto-o_ZWNKmYq_A%40mail.gmail.com.

[go-nuts] [security] Go 1.17.3 and Go 1.16.10 are released

['Than McIntosh' via golang-nuts]

Hi gophers,

We have just released Go versions 1.17.3 and 1.16.10, minor point releases.

These minor releases include two security fixes following the security
policy :

   -

   archive/zip: don't panic on (*Reader).Open

Reader.Open (the API implementing io/fs.FS introduced in Go 1.16) can be
made to panic by an attacker providing either a crafted ZIP archive
containing completely invalid names or an empty filename argument.

Thank you to Colin Arnott, SiteHost and Noah Santschi-Cooney, Sourcegraph
Code Intelligence Team for reporting this issue.

This is CVE-2021-41772 and Go issue golang.org/issue/48085
.

   -

   debug/macho: invalid dynamic symbol table command can cause panic

Malformed binaries parsed using Open or OpenFat can cause a panic when
calling ImportedSymbols, due to an out-of-bounds slice operation.

Thanks to Burak Çarıkçı - Yunus Yıldırım (CT-Zer0 Crypttech) for reporting
this issue

This is CVE-2021-41771 and Go issue golang.org/issue/48990
.

View the release notes for more information:

https://golang.org/doc/devel/release.html#go1.17.minor

You can download binary and source distributions from the Go web site:

https://golang.org/dl/

To compile from source using a Git clone, update to the release with

"git checkout go1.17.3" and build as usual.

Thanks to everyone who contributed to the releases.

Cheers,

Than and Dmitri for the Go team

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BUr55HQdo%3Di0MRK_sBKd4U1_65DqRq2089wStKGtmuqweqjHQ%40mail.gmail.com.

Re: [go-nuts] gollvm for LLVM13

['Than McIntosh' via golang-nuts]

Hi,

I've been in the process of updating gollvm to sync with the recently
submitted Go 1.17 changes in gofrontend. I just checked in a couple of CLs
that should help.

Please sync your gollvm client ; if you build with
0f0479aa582cfa3bd9c17bd7d41d2e2bc9991958 for gollvm (plus tip of gofrontend
and LLVM llvmorg-13.0.0-rc3) that should work.

Thanks, Than


On Tue, Sep 21, 2021 at 11:24 PM Khanh TN  wrote:

> Hi,
> While running the latest commit of gollvm (with latest commit of
> gofrontend, libbacktrace, libffi) with LLVM13 (commit llvmorg-13.0.0-rc3),
> I encountered this error:
>
> llvm-project/build13/tools/gollvm/libgo/version.go:9:6: error:
> redefinition of 'ArchFamilyType'
> llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/runtime/internal/sys/arch.go:17:7:
> note: previous definition of 'ArchFamily' was here
>
>
> Is there a version that works with LLVM13 (preferably llvmorg-13.0.0-rc3)?
>
> Thanks!
>
> Khanh
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/846afef0-fd26-4eb2-aa36-90b6ccbdbb7bn%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BUr55EGVfOzX74HKm7dEPMvX_1nx5hy%2BU4BMtYOXL%3DAM8hzBQ%40mail.gmail.com.

Re: [go-nuts] Simplifying LLVM bitcode from gollvm

['Than McIntosh' via golang-nuts]

I feel as though we're getting into the realm of "what is the sound of one
hand clapping"... ?

Than


On Mon, Sep 13, 2021 at 1:51 PM Ian Lance Taylor  wrote:

> On Mon, Sep 13, 2021 at 6:03 AM Khanh TN  wrote:
> >
> > Also, from what I understand, if noone imports my package, I can also
> remove the "module asm" lines at the start. Is that right?
>
> What is the use of a package that nobody imports?
>
> Ian
>
>
> > On Monday, September 13, 2021 at 9:18:20 AM UTC+8 Khanh TN wrote:
> >>
> >> Hi,
> >> Thanks, Than, for the answer.
> >> So, if the .go file I'm compiling is the one with "package main" "func
> main()", I can remove the "module asm" lines without any consequences?
> >>
> >> Khanh
> >>
> >> On Friday, September 10, 2021 at 9:09:12 PM UTC+8 th...@google.com
> wrote:
> >>>
> >>> Hi,
> >>>
> >>> The "module asm" at the start of your bitcode dump is actually the
> export data for the package, so it plays a pretty crucial role.
> >>>
> >>> Deleting the export data from the "main" package may work in some
> cases (since nobody imports main), but it will certainly cause problems if
> you delete the export data from some other non-main package.
> >>>
> >>> Export data tends to be substantial because it is based on the
> transitive closure of the imported packages (e.g. "fmt" imports "io", then
> "io" imports "sync", then "sync" imports "runtime", and so on).
> >>>
> >>> On the other hand, Go export data is way smaller than the volume of
> header information that would have to be consumed by a C++ compiler when
> building your average C++ source file.
> >>>
> >>> Than
> >>>
> >>> On Thu, Sep 9, 2021 at 6:31 AM Khanh TN  wrote:
> 
>  A Helloworld written in C++ is around 75 lines in LLVM IR.
>  However, a Helloworld written in Golang compiled with gollvm is
> around 900/1000 lines of .ll file. I produced the LLVM IR with instructions
> from https://go.googlesource.com/gollvm/
>  I'm using LLVM11, so, older compatible commit of gollvm, not sure
> newer versions are different.
> 
>  How can I produce shorter/simplified LLVM IR?
>  Thanks!
> 
>  Cheers,
>  Khanh
> 
> 
>  P/S:
>  An LLVM IR file has a lot of  module asm at the start, like:
>  module asm "\09.section \22.go_export\22,\22e\22,@progbits"
>  module asm "\09.ascii \22v3;\\n\22"
>  module asm "\09.ascii \22package \22"
>  module asm "\09.ascii \22main\22"
>  module asm "\09.ascii \22\\n\22"
>  module asm "\09.ascii \22pkgpath \22"
>  module asm "\09.ascii \22main\22"
> 
>  I figure I can delete all the module asm line and my program still
> runs correctly (I only tested 2 times on simple programs). Is this a legit
> optimization?
> 
>  --
>  You received this message because you are subscribed to the Google
> Groups "golang-nuts" group.
>  To unsubscribe from this group and stop receiving emails from it,
> send an email to golang-nuts...@googlegroups.com.
>  To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/8ee91024-b270-4d1e-99b9-dbcd3e25d4c4n%40googlegroups.com
> .
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "golang-nuts" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to golang-nuts+unsubscr...@googlegroups.com.
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/abf02438-5740-46e1-8577-2e001b3960f7n%40googlegroups.com
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAOyqgcV%2BMR2FBArbR6ZNgCgs1DbO_Hwccu%2BOD3SuvLLRm6%2Bqcg%40mail.gmail.com
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BUr55EwO3HOPK7bw819ic_xDBFJhPCgPDmVkb%2BO%3Dgfu8%2B85Eg%40mail.gmail.com.

Re: [go-nuts] Simplifying LLVM bitcode from gollvm

['Than McIntosh' via golang-nuts]

Hi,

The "module asm" at the start of your bitcode dump is actually the export
data for the package, so it plays a pretty crucial role.

Deleting the export data from the "main" package may work in some cases
(since nobody imports main), but it will certainly cause problems if you
delete the export data from some other non-main package.

Export data tends to be substantial because it is based on the transitive
closure of the imported packages (e.g. "fmt" imports "io", then "io"
imports "sync", then "sync" imports "runtime", and so on).

On the other hand, Go export data is *way* smaller than the volume of
header information that would have to be consumed by a C++ compiler when
building your average C++ source file.

Than

On Thu, Sep 9, 2021 at 6:31 AM Khanh TN  wrote:

> A Helloworld written in C++ is around 75 lines in LLVM IR.
> However, a Helloworld written in Golang compiled with gollvm is around
> 900/1000 lines of .ll file. I produced the LLVM IR with instructions from
> https://go.googlesource.com/gollvm/
> I'm using LLVM11, so, older compatible commit of gollvm, not sure newer
> versions are different.
>
> How can I produce shorter/simplified LLVM IR?
> Thanks!
>
> Cheers,
> Khanh
>
>
> P/S:
> An LLVM IR file has a lot of  module asm at the start, like:
> module asm "\09.section \22.go_export\22,\22e\22,@progbits"
> module asm "\09.ascii \22v3;\\n\22"
> module asm "\09.ascii \22package \22"
> module asm "\09.ascii \22main\22"
> module asm "\09.ascii \22\\n\22"
> module asm "\09.ascii \22pkgpath \22"
> module asm "\09.ascii \22main\22"
>
> I figure I can delete all the module asm line and my program still  runs
> correctly (I only tested 2 times on simple programs). Is this a legit
> optimization?
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/8ee91024-b270-4d1e-99b9-dbcd3e25d4c4n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BUr55FiSx-NmjuM1ub6czS68Dr30ybJFbYt3QSC_4%2BOt3Jp0w%40mail.gmail.com.

[go-nuts] [security] Go 1.17.1 and Go 1.16.8 are released

['Than McIntosh' via golang-nuts]

Hello gophers,

We have just released Go versions 1.17.1 and 1.16.8 minor point releases.

These minor releases include a security fix according to the new security
policy (#44918 ).

The fix for CVE-2021-33196 can be bypassed by crafted inputs. As a result,
the NewReader and OpenReader functions in archive/zip
 can still cause a panic or an
unrecoverable fatal error when reading an archive that claims to contain a
large number of files, regardless of its actual size.

This is issue #47801  and
CVE-2021-39293.

Thanks to the OSS-Fuzz project for discovering this issue and to Emmanuel
Odeke for reporting it.

View the release notes for more information:

https://golang.org/doc/devel/release.html#go1.17.minor


You can download binary and source distributions from the Go web site:

https://golang.org/dl/

To compile from source using a Git clone, update to the release with

"git checkout go1.17.1" and build as usual.

Thanks to everyone who contributed to the releases.

Cheers,

Than, Cherry, and Alex for the Go team

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BUr55E9imb-y2WBgyF3yvDJdC8Swpq3KrXTxshx0_PB4Lg0Hw%40mail.gmail.com.

Re: [go-nuts] Understanding gollvm garbage collection

['Than McIntosh' via golang-nuts]

>Also does gollvm create a new stack map? I think it does not use the stack
map created by LLVM.

gollvm does not use stack maps of the format used by LLVM, correct.

Than


On Fri, Jul 9, 2021 at 11:17 AM Kavindu Gimhan Zoysa 
wrote:

> Also does gollvm create a new stack map? I think it does not use the stack
> map 
> created by LLVM.
>
> Thank you,
> Kavindu
> On Friday, 9 July 2021 at 19:35:03 UTC+5:30 Kavindu Gimhan Zoysa wrote:
>
>> Thank you Than, Is go scheduler is responsible for running GC?
>>
>> On Friday, 9 July 2021 at 19:14:43 UTC+5:30 th...@google.com wrote:
>>
>>> >1. If we do not enable the gc (-enable-gc=1), GC assumes all the stack
>>> memory blocks are pointed to the heap.
>>> >2. If gc is enabled, it inserts statepoints and generates the stack map
>>> (by LLVM). Using that stack map, GC can find where the actual heap
>>> references are located.
>>>
>>> Yes, this is basically correct.
>>>
>>>
>>> >As per my understanding, GC is common for both cases (still I was
>>> unbale to find the source code for this GC).
>>>
>>> The GC is located in the Go runtime, the version incorporated into libgo
>>> in gofrontend. See
>>>
>>>
>>> https://go.googlesource.com/gofrontend/+/01cb2b5e69a2d08ef3cc1ea023c22ed9b79f5114/libgo/go/runtime/mgc.go
>>>
>>> Cheers, Than
>>>
>>> On Fri, Jul 9, 2021 at 9:16 AM Kavindu Gimhan Zoysa 
>>> wrote:
>>>
 Hi all,

 By looking at the source code, and other mail theads in group, I was
 able to understand the sopport of GC by gollvm upto some extend.

 1. If we do not enable the gc (-enable-gc=1), GC assumes all the stack
 memory blocks are pointed to the heap.
 2. If gc is enabled, it inserts statepoints and generates the stack map
 (by LLVM). Using that stack map, GC can find where the actual heap
 references are located.

 As per my understanding, GC is common for both cases (still I was
 unbale to find the source code for this GC).

 I really appreciate if you can correct me if I am wrong.

 Thank you,
 Kavindu

 --
 You received this message because you are subscribed to the Google
 Groups "golang-nuts" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to golang-nuts...@googlegroups.com.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/golang-nuts/c57dfdf2-dfc4-4f81-b432-739165065d87n%40googlegroups.com
 
 .

>>> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/44fea268-5afa-4dab-869b-414deac6ebe4n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BUr55GxnrTu53DPgPzkumqr0pfA%3D3t-Y206HG4MpOVvmZsTqA%40mail.gmail.com.

Re: [go-nuts] Understanding gollvm garbage collection

['Than McIntosh' via golang-nuts]

>1. If we do not enable the gc (-enable-gc=1), GC assumes all the stack
memory blocks are pointed to the heap.
>2. If gc is enabled, it inserts statepoints and generates the stack map
(by LLVM). Using that stack map, GC can find where the actual heap
references are located.

Yes, this is basically correct.

>As per my understanding, GC is common for both cases (still I was unbale
to find the source code for this GC).

The GC is located in the Go runtime, the version incorporated into libgo in
gofrontend. See

https://go.googlesource.com/gofrontend/+/01cb2b5e69a2d08ef3cc1ea023c22ed9b79f5114/libgo/go/runtime/mgc.go

Cheers, Than

On Fri, Jul 9, 2021 at 9:16 AM Kavindu Gimhan Zoysa 
wrote:

> Hi all,
>
> By looking at the source code, and other mail theads in group, I was able
> to understand the sopport of GC by gollvm upto some extend.
>
> 1. If we do not enable the gc (-enable-gc=1), GC assumes all the stack
> memory blocks are pointed to the heap.
> 2. If gc is enabled, it inserts statepoints and generates the stack map
> (by LLVM). Using that stack map, GC can find where the actual heap
> references are located.
>
> As per my understanding, GC is common for both cases (still I was unbale
> to find the source code for this GC).
>
> I really appreciate if you can correct me if I am wrong.
>
> Thank you,
> Kavindu
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/c57dfdf2-dfc4-4f81-b432-739165065d87n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BUr55FRSdpEEJzBWCLg9zDj_-kRyJsK1r_Jp7cwSF%2B0zfPpuQ%40mail.gmail.com.

Re: [go-nuts] Reason to use different address space in gollvm

['Than McIntosh' via golang-nuts]

Hi again,

Sorry for the delay, I have been offline for a while.

You wrote:
>Regarding address spaces, I saw that there is a pass to remove address
space casts. But if I generate IR using `llvm-goc -dump-ir -enable-gc=1
test.go` for the following go file, I still can see the addrspacecast
instruction. What is the reason to see that addrspacecast? I feel that pass
is not running. Can you help me to understand this problem?

A couple of things on this.

First, the "-dump-ir" option to llvm-goc shows the LLVM IR after the front
end and bridge are done with creating it -- at this point no LLVM passes
will have been run, so you would not expect to see any address space casts
removed.  Probably what you want here is "-emit-llvm", which will show LLVM
IR after all the various module and function passes have run (before the
switch to machine-dependent IR). Example:

 $ llvm-goc -S -emit-llvm -enable-gc=1 test.go
 $ cat test.ll
 ...
 $

A second thing is that the cast-removal pass you mention isn't removing
every cast, only casts on initialized global variables fed with constants.
If you look at this source code

https://go.googlesource.com/gollvm/+/38bada572789a19cf881201c923e6b56ed32ae53/passes/RemoveAddrSpace.cpp#95

you can see that it's visiting only initialized globals. If you want to
examples of cast removal, try running your compile on a larger and more
interesting test case, like

  https://golang.org/test/method5.go

In general if you are unsure about whether a pass is running and/or what
the effects of the pass are, there are developer options you can try (note:
available only in a pure debug build) that can show you more. Example:

 # Dump LLVM IR before a pass
 $ ./bin/llvm-goc -O2 -c -emit-llvm -S -enable-gc=1 -mllvm
-print-before=remove-addrspacecast test.go 1> before.dump.txt 2>&1

 # Dump LLVM IR after a pass
 $ ./bin/llvm-goc -O2 -c -emit-llvm -S -enable-gc=1 -mllvm
-print-after=remove-addrspacecast test.go 1> after.dump.txt 2>&1

Hope this helps.

Thanks, Than

On Mon, Jul 5, 2021 at 3:08 AM Kavindu Gimhan Zoysa 
wrote:

> Hi,
>
> Regarding address spaces, I saw that there is a pass to remove address
> space casts. But if I generate IR using `*llvm-goc -dump-ir -enable-gc=1
> test.go*` for the following go file, I still can see the *addrspacecast*
> instruction. What is the reason to see that *addrspacecast? *I feel that
> pass is not running. Can you help me to understand this problem?
>
>
> *package main*
>
> *func main() {*
> *   _ = stackIt2()*
> *}*
> *//go:noinline*
> *func stackIt2() *int {*
> *   y := 2*
> *   res := y * 2*
> *   return *
> *}*
>
> Thank you,
> Kavindu
> On Tuesday, 29 June 2021 at 18:22:14 UTC+5:30 th...@google.com wrote:
>
>> See https://llvm.org/docs/Statepoints.html for more on this.
>>
>> Thanks, Than
>>
>>
>> On Mon, Jun 28, 2021 at 5:40 AM Kavindu Gimhan Zoysa 
>> wrote:
>>
>>> Hi all,
>>>
>>> Can you please explain the reason to use different address space when GC
>>> is enabled as shown in the below line?
>>>
>>>
>>> https://go.googlesource.com/gollvm/+/refs/heads/master/driver/CompileGo.cpp#559
>>>
>>> Thank you,
>>> Kavindu
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to golang-nuts...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/d95934ca-4488-4071-8c07-bb33122be387n%40googlegroups.com
>>> 
>>> .
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/c26ff4b9-84a9-4aa2-a450-5d1796aba1c0n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BUr55Gqi9p4jDbiUWAAE_amhMsrCLf4gUc5-XTR8wd4pVjMEg%40mail.gmail.com.

Re: [go-nuts] Re: Reason to add a pass to remote address space

['Than McIntosh' via golang-nuts]

The commit message for  https://go-review.googlesource.com/c/152001
describes the motivation for this pass.

Thanks, Than


On Fri, Jul 2, 2021 at 4:51 AM Kavindu Gimhan Zoysa 
wrote:

> Hi all,
>
> The subject of the above mail should be corrected as "
> *Reason to add a pass to remove address space"*
> Thank you,
> Kavindu
> On Friday, 2 July 2021 at 12:36:26 UTC+5:30 Kavindu Gimhan Zoysa wrote:
>
>> Hi all,
>>
>> Can you please let me know the reason to add a pass to remove address
>> spaces as shown below?
>>
>> https://go.googlesource.com/gollvm/+/refs/heads/master/passes/RemoveAddrSpace.cpp#30
>>
>> As per the comment in CompileGo.cpp, this is done right before the
>> lowering to Machine IR.
>>
>> Thank you,
>> Kavindu
>>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/24069e18-3e62-4266-a442-ff00ab63b85an%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BUr55EbdXbOANh%2B_jgA6udhBm54gNG7ZwDN2Odo%2B9KVyQGAzQ%40mail.gmail.com.

Re: [go-nuts] Hi all,

['Than McIntosh' via golang-nuts]

OK, fix https://go-review.googlesource.com/c/gollvm/+/331729 submitted.
Thanks for reporting.

Than


On Tue, Jun 29, 2021 at 1:30 PM Than McIntosh  wrote:

> I sent a CL to fix this, please stay tuned.
> https://go-review.googlesource.com/c/gollvm/+/331729
>
> Thanks, Than
>
>
> On Sun, Jun 27, 2021 at 12:22 AM Kavindu Gimhan Zoysa <
> kavindu...@gmail.com> wrote:
>
>> Hi,
>>
>> *cmake -DCMAKE_INSTALL_PREFIX=/my/install/dir -DCMAKE_BUILD_TYPE=Release
>> -DLLVM_USE_LINKER=gold -G Ninja ../llvm-project/llvm*
>> I have tried to run the above command with updated third-party
>> repositories(latest llvm-project) and got the below error. Any idea on this?
>>
>> *error: ‘class llvm::opt::OptTable’ has no member named ‘PrintHelp’; did
>> you mean ‘printHelp’?*
>> *  104 | opts_->PrintHelp(errs(), progname, "Gollvm (LLVM-based Go
>> compiler)",*
>> *  |^*
>> *  |printHelp*
>> *ninja: build stopped: subcommand failed.*
>>
>>
>> On Thursday, 24 June 2021 at 23:25:20 UTC+5:30 Kavindu Gimhan Zoysa wrote:
>>
>>> Thank you. Do not I need to check out for a special commit? Can I build
>>> the gollvm by checking out the latest commits in all dependant
>>> repositories(llvm-project, libbacktrace, libgo etc)?
>>>
>>> Thank you,
>>> Kavindu
>>> On Thursday, 24 June 2021 at 21:06:28 UTC+5:30 th...@google.com wrote:
>>>
 This change has been submitted; if you update your gollvmn repo you
 should be able to build cleanly now.

 Thanks, Than


 On Thu, Jun 24, 2021 at 9:22 AM Than McIntosh  wrote:

> Hello,
>
> I sent a CL to fix this problem:
> https://go-review.googlesource.com/c/gollvm/+/330609. I'll let you
> know when it is submitted.
>
> Thanks, Than
>
>
> On Wed, Jun 23, 2021 at 5:30 PM Than McIntosh 
> wrote:
>
>> Hi,
>>
>> I'll take a look -- stay tuned.
>>
>> Than
>>
>>
>> On Wed, Jun 23, 2021 at 3:04 PM Kavindu Gimhan Zoysa <
>> kavin...@gmail.com> wrote:
>>
>>> By following `gollvm` document I started to build it. But I got this
>>> error in the middle of the build process.
>>>
>>> */home/kavindu/GIT/llvm-project/llvm/tools/gollvm/passes/GC.cpp:20:10:
>>> fatal error: llvm/CodeGen/GCStrategy.h: No such file or directory*
>>> *   20 | #include "llvm/CodeGen/GCStrategy.h"*
>>> *  |  ^~~*
>>> *compilation terminated.*
>>>
>>> Could you please help me to solve this issue.
>>> I have used the llvm-project's main branch to build this. Do we need
>>> to strict to a special commit in llvm-project to build gollvm?
>>>
>>> I am building this on ubuntu 20.04
>>>
>>> Thank you,
>>> Kavindu
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it,
>>> send an email to golang-nuts...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/c33bd416-c366-4fb0-a966-17553ffd0a76n%40googlegroups.com
>>> 
>>> .
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/919540c7-acb0-4324-8fbe-f90049515315n%40googlegroups.com
>> 
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BUr55HuKvmugwgqe4Eq-bVGdMnbJ4q4siTmVQn9T9PLZ4RBow%40mail.gmail.com.

Re: [go-nuts] Re: Error when running llvm-goc

['Than McIntosh' via golang-nuts]

You wrote:
>If I run `go build test.go`, when does llvm-goc executable start to run?
Does go build command replace its' existing compiler with llvm-goc?

The "go" command, the program that orchestrates the building of Go
programs, runs 'llvm-goc' at each point where it needs to compile a Go
package, and then at the point where it needs to do a final link step to
create an executable.

You can learn more about how the compiler is invoked by the Go command
(what is happening "under the hood" so to speak) by using the "-x" option
with go build. E.g.

  $ go clean -cache
  $ go build -x myprogram.go 1> transcript.txt 2>&1
  $

then inspect "transcript.txt" to see how the compiler is being invoked.

If your program "myprogram.go" imports packages P1 and P2, then in the
transcript
you would expect to see (at minimum) an invocation of llvm-goc for P1, for
P2, then for the main package,  and for the final link.

Also:
>Does go build command replace its' existing compiler with llvm-goc?

More or less. The set of command line flags supported by the two compilers
is completely different (and there are many other implementation
differences), so there will be some differences in the build steps.

Than




On Sat, Jun 26, 2021 at 1:10 PM Kavindu Gimhan Zoysa 
wrote:

> Hi,
>
> Thank you for your detailed explanation. I will try your suggestions and
> let you know.
>
> I used this cmake command.
> `cmake -DCMAKE_INSTALL_PREFIX=/my/install/dir -DCMAKE_BUILD_TYPE=Release
> -DLLVM_USE_LINKER=gold -G Ninja ../llvm-project/llvm`
>
> Then I used, `ninja gollvm`, and it was successful.
>
> Also, I used, `ninja install-gollvm`, but nothing happens.
>
> I have a couple of unclear points. As I know, llvm-goc is a tool that
> generates llvm IR for a go source code.
> If I run `go build test.go`, when does llvm-goc executable start to run?
> Does go build command replace its' existing compiler with llvm-goc?
>
> Thank you,
> Kavindu
> On Friday, 25 June 2021 at 19:52:16 UTC+5:30 th...@google.com wrote:
>
>> Hello again,
>>
>> Couple of things.
>>
>> First, it is important to keep in mind that the "llvm-goc" binary is not
>> intended to be used as a top level go compiler, in the same way that the
>> "gcc" or "clang" commands are used as top-level C/C++ compilers. The normal
>> use case is to use "go build" as opposed to invoking llvm-goc directly.
>> Just to recap: build the 'install-gollvm' ninja target (as described in
>> https://go.googlesource.com/gollvm/#installing), prepend the install dir
>> "bin" directory in your path, and then run "go build".
>>
>> It's also problematic to run llvm-goc directly out of the build area
>> instead of doing and install and using the copy in the install dir. For
>> example, if I do a build of llvm-goc in my LLVM build area, then invoke it
>> directly on a small Go program, this is what I see:
>>
>> $ ./bin/llvm-goc smallmain.go
>> /usr/bin/ld.gold: error: cannot find -lgobegin
>> /usr/bin/ld.gold: error: cannot find -lgo
>> /usr/lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu/crt1.o:function
>> _start: error: undefined reference to 'main'
>> :1: error: undefined reference to
>> 'runtime.registerTypeDescriptors'
>> smallmain.go:4: error: undefined reference to 'runtime.printlock'
>> smallmain.go:4: error: undefined reference to 'runtime.printint'
>> smallmain.go:4: error: undefined reference to 'runtime.printnl'
>> smallmain.go:4: error: undefined reference to 'runtime.printunlock'
>> $
>>
>> Here the compiler is unable to find the right runtime libraries. I'll see
>> if I can update the documentation to make this a little clearer.
>>
>> Regarding the crash you're seeing when building from
>>
>>  LLVM: 43ff75f2c3feef64f9d73328230d34dac8832a91
>> gollvm: 44a7a475cfd3b871b7a5a0941b8ab1ea9d489adc
>> gofrontend: be0d2cc2df9f98d967c242594838f86362dae2e7
>> libbacktrace: 5a99ff7fed66b8ea8f09c9805c138524a7035ece
>> libffi: 737d4faa00d681b4c758057f67e1a02d813d01c2
>>
>>
>> Sorry, but I can't reproduce your crash (I did another build using the
>> config above and it seems to work ok). What is the exact cmake command
>> you're using to set up your build area?
>>
>> You might also try this: in your LLVM build area, run "ninja
>> llvm-symbolizer" and then set
>>
>> export LLVM_SYMBOLIZER=${HERE}/bin/llvm-symbolizer
>>
>> then rerun the failing "llvm-goc" invocation, that might give you a
>> better stack trace.
>>
>> Thanks, Than
>>
>>
>>
>> On Thu, Jun 24, 2021 at 2:53 PM Kavindu Gimhan Zoysa 
>> wrote:
>>
>>> I did not use any *go build* command. Sorry if I missed anything. These
>>> are the steps I followed.
>>>
>>> 1. Build gollvm referring to the official documentation. I followed the
>>> steps until https://go.googlesource.com/gollvm/#cmakeninja.
>>> 2. I was able to see the *llvm-goc *in the bin folder.  I export the
>>> path using '*export
>>> LD_LIBRARY_PATH=/build-debug/libgo/x86_64-unknown-linux-gnu' *
>>> command.
>>> 3. Then I tried to dump the llvm IR using '*../bin/llvm-goc -S test.go
>>> 

Re: [go-nuts] Hi all,

['Than McIntosh' via golang-nuts]

I sent a CL to fix this, please stay tuned.
https://go-review.googlesource.com/c/gollvm/+/331729

Thanks, Than


On Sun, Jun 27, 2021 at 12:22 AM Kavindu Gimhan Zoysa 
wrote:

> Hi,
>
> *cmake -DCMAKE_INSTALL_PREFIX=/my/install/dir -DCMAKE_BUILD_TYPE=Release
> -DLLVM_USE_LINKER=gold -G Ninja ../llvm-project/llvm*
> I have tried to run the above command with updated third-party
> repositories(latest llvm-project) and got the below error. Any idea on this?
>
> *error: ‘class llvm::opt::OptTable’ has no member named ‘PrintHelp’; did
> you mean ‘printHelp’?*
> *  104 | opts_->PrintHelp(errs(), progname, "Gollvm (LLVM-based Go
> compiler)",*
> *  |^*
> *  |printHelp*
> *ninja: build stopped: subcommand failed.*
>
>
> On Thursday, 24 June 2021 at 23:25:20 UTC+5:30 Kavindu Gimhan Zoysa wrote:
>
>> Thank you. Do not I need to check out for a special commit? Can I build
>> the gollvm by checking out the latest commits in all dependant
>> repositories(llvm-project, libbacktrace, libgo etc)?
>>
>> Thank you,
>> Kavindu
>> On Thursday, 24 June 2021 at 21:06:28 UTC+5:30 th...@google.com wrote:
>>
>>> This change has been submitted; if you update your gollvmn repo you
>>> should be able to build cleanly now.
>>>
>>> Thanks, Than
>>>
>>>
>>> On Thu, Jun 24, 2021 at 9:22 AM Than McIntosh  wrote:
>>>
 Hello,

 I sent a CL to fix this problem:
 https://go-review.googlesource.com/c/gollvm/+/330609. I'll let you
 know when it is submitted.

 Thanks, Than


 On Wed, Jun 23, 2021 at 5:30 PM Than McIntosh  wrote:

> Hi,
>
> I'll take a look -- stay tuned.
>
> Than
>
>
> On Wed, Jun 23, 2021 at 3:04 PM Kavindu Gimhan Zoysa <
> kavin...@gmail.com> wrote:
>
>> By following `gollvm` document I started to build it. But I got this
>> error in the middle of the build process.
>>
>> */home/kavindu/GIT/llvm-project/llvm/tools/gollvm/passes/GC.cpp:20:10:
>> fatal error: llvm/CodeGen/GCStrategy.h: No such file or directory*
>> *   20 | #include "llvm/CodeGen/GCStrategy.h"*
>> *  |  ^~~*
>> *compilation terminated.*
>>
>> Could you please help me to solve this issue.
>> I have used the llvm-project's main branch to build this. Do we need
>> to strict to a special commit in llvm-project to build gollvm?
>>
>> I am building this on ubuntu 20.04
>>
>> Thank you,
>> Kavindu
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it,
>> send an email to golang-nuts...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/c33bd416-c366-4fb0-a966-17553ffd0a76n%40googlegroups.com
>> 
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/919540c7-acb0-4324-8fbe-f90049515315n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BUr55HqrndjHmuK%3DBsgP4BmwBMHTir5S77Rcv4eBu7DsgydTw%40mail.gmail.com.

Re: [go-nuts] Reason to use different address space in gollvm

['Than McIntosh' via golang-nuts]

See https://llvm.org/docs/Statepoints.html for more on this.

Thanks, Than


On Mon, Jun 28, 2021 at 5:40 AM Kavindu Gimhan Zoysa 
wrote:

> Hi all,
>
> Can you please explain the reason to use different address space when GC
> is enabled as shown in the below line?
>
>
> https://go.googlesource.com/gollvm/+/refs/heads/master/driver/CompileGo.cpp#559
>
> Thank you,
> Kavindu
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/d95934ca-4488-4071-8c07-bb33122be387n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BUr55F5qRyc-rW0ggBB3L2LwfSNta%2BDEda%2BEjQ45cN2gLkYMw%40mail.gmail.com.

Re: [go-nuts] How to verify whether gollvm is picked

['Than McIntosh' via golang-nuts]

If would help if you could share your exact cmake invocation I think.

If your cmake invocation looks like

cmake \
   -DCMAKE_BUILD_TYPE=RelWithDebInfo \
   -DCMAKE_INSTALL_PREFIX=/tmp/myinstall \
   -DCMAKE_C_COMPILER=/usr/bin/clang-10 \
   -DCMAKE_ASM_COMPILER=/usr/bin/clang-10 \
   -DCMAKE_CXX_COMPILER=/usr/bin/clang++-10 \
   -G Ninja ../llvm-project/llvm

Then you should be prepending /tmp/myinstall/bin to your path.

Thanks, Than

On Sun, Jun 27, 2021 at 2:59 AM Kavindu Gimhan Zoysa 
wrote:

> Hi all,
>
> I have ran the commands in https://go.googlesource.com/gollvm/#installing,
> (I did not run `ninja install-gollvm`). Then I set the path of bin folder
> to my $PATH using `export PATH=build-debug/bin:$PATH`.
>
> Finally, I was able to run `go build/run test.go` successfully.
>
> But my problem is since I have already installed golang to my machine
> before install gollvm, how do I verify that go build command picked gollvm,
> instead of golang's compiler?
>
> Thank you,
> Kavindu
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/6623d44d-da35-4c54-8c90-9e6a8cc9cb00n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BUr55G-rR6Uco72zA3Em_QFMgYrL39quNc22znKhDOZ4qEhgw%40mail.gmail.com.

Re: [go-nuts] Re: Error when running llvm-goc

['Than McIntosh' via golang-nuts]

Hello again,

Couple of things.

First, it is important to keep in mind that the "llvm-goc" binary is not
intended to be used as a top level go compiler, in the same way that the
"gcc" or "clang" commands are used as top-level C/C++ compilers. The normal
use case is to use "go build" as opposed to invoking llvm-goc directly.
Just to recap: build the 'install-gollvm' ninja target (as described in
https://go.googlesource.com/gollvm/#installing), prepend the install dir
"bin" directory in your path, and then run "go build".

It's also problematic to run llvm-goc directly out of the build area
instead of doing and install and using the copy in the install dir. For
example, if I do a build of llvm-goc in my LLVM build area, then invoke it
directly on a small Go program, this is what I see:

$ ./bin/llvm-goc smallmain.go
/usr/bin/ld.gold: error: cannot find -lgobegin
/usr/bin/ld.gold: error: cannot find -lgo
/usr/lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu/crt1.o:function
_start: error: undefined reference to 'main'
:1: error: undefined reference to
'runtime.registerTypeDescriptors'
smallmain.go:4: error: undefined reference to 'runtime.printlock'
smallmain.go:4: error: undefined reference to 'runtime.printint'
smallmain.go:4: error: undefined reference to 'runtime.printnl'
smallmain.go:4: error: undefined reference to 'runtime.printunlock'
$

Here the compiler is unable to find the right runtime libraries. I'll see
if I can update the documentation to make this a little clearer.

Regarding the crash you're seeing when building from

 LLVM: 43ff75f2c3feef64f9d73328230d34dac8832a91
gollvm: 44a7a475cfd3b871b7a5a0941b8ab1ea9d489adc
gofrontend: be0d2cc2df9f98d967c242594838f86362dae2e7
libbacktrace: 5a99ff7fed66b8ea8f09c9805c138524a7035ece
libffi: 737d4faa00d681b4c758057f67e1a02d813d01c2


Sorry, but I can't reproduce your crash (I did another build using the
config above and it seems to work ok). What is the exact cmake command
you're using to set up your build area?

You might also try this: in your LLVM build area, run "ninja
llvm-symbolizer" and then set

export LLVM_SYMBOLIZER=${HERE}/bin/llvm-symbolizer

then rerun the failing "llvm-goc" invocation, that might give you a better
stack trace.

Thanks, Than



On Thu, Jun 24, 2021 at 2:53 PM Kavindu Gimhan Zoysa 
wrote:

> I did not use any *go build* command. Sorry if I missed anything. These
> are the steps I followed.
>
> 1. Build gollvm referring to the official documentation. I followed the
> steps until https://go.googlesource.com/gollvm/#cmakeninja.
> 2. I was able to see the *llvm-goc *in the bin folder.  I export the path
> using '*export
> LD_LIBRARY_PATH=/build-debug/libgo/x86_64-unknown-linux-gnu' *
> command.
> 3. Then I tried to dump the llvm IR using '*../bin/llvm-goc -S test.go
> -dump-ir', *and it was successful.
> 4. Then I ran this command '*./bin/llvm-goc test.go'*. I got the above
> error.
>
> Did i miss anything?
>
> Thank you,
> Kavindu
> On Friday, 25 June 2021 at 00:01:41 UTC+5:30 th...@google.com wrote:
>
>> Could you please post the complete "go build" command?
>>
>> Thanks, Than
>>
>> On Thu, Jun 24, 2021 at 2:05 PM Kavindu Gimhan Zoysa 
>> wrote:
>>
>>> Hi all,
>>>
>>> Still, I was unable to figure out the reason for the above error. Really
>>> appreciate your help.
>>>
>>> Thank you,
>>> Kavindu
>>>
>>> On Thursday, 24 June 2021 at 12:06:32 UTC+5:30 Kavindu Gimhan Zoysa
>>> wrote:
>>>
 Hi all,

 I have build the gollvm and now I am trying to run it. So I run
 follwing command against a simple go source code. I am getting below error.
 Really appreciate your input to solve this issue.

 command :
 *./bin/llvm-goc test.go*

 error:
 *llvm-goc:
 /home/kavindu/GIT/llvm-project/llvm/tools/gollvm/driver/Action.cpp:51:
 const char* gollvm::driver::Action::resultFileSuffix() const: Assertion
 `false' failed.*
 *../bin/llvm-goc(+0x2c46a3f)[0x55a113e42a3f]*
 *../bin/llvm-goc(+0x2c46ad6)[0x55a113e42ad6]*
 *../bin/llvm-goc(+0x2c44829)[0x55a113e40829]*
 *../bin/llvm-goc(+0x2c46387)[0x55a113e42387]*
 */lib/x86_64-linux-gnu/libpthread.so.0(+0x153c0)[0x7f67e0aad3c0]*
 */lib/x86_64-linux-gnu/libc.so.6(gsignal+0xcb)[0x7f67e056818b]*
 */lib/x86_64-linux-gnu/libc.so.6(abort+0x12b)[0x7f67e0547859]*
 */lib/x86_64-linux-gnu/libc.so.6(+0x25729)[0x7f67e0547729]*
 */lib/x86_64-linux-gnu/libc.so.6(+0x36f36)[0x7f67e0558f36]*
 *../bin/llvm-goc(+0x827e69)[0x55a111a23e69]*
 *../bin/llvm-goc(+0x8167d5)[0x55a111a127d5]*
 *../bin/llvm-goc(+0x81db02)[0x55a111a19b02]*
 *../bin/llvm-goc(+0x81ddfb)[0x55a111a19dfb]*
 *../bin/llvm-goc(+0x811cb9)[0x55a111a0dcb9]*

 */lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0x7f67e05490b3]*
 *../bin/llvm-goc(+0x81112e)[0x55a111a0d12e]*
 *PLEASE submit a bug report to https://bugs.llvm.org/
  and include the crash backtrace.*
 *Stack dump:*
 *0. Program 

Re: [go-nuts] Re: Error when running llvm-goc

['Than McIntosh' via golang-nuts]

Could you please post the complete "go build" command?

Thanks, Than

On Thu, Jun 24, 2021 at 2:05 PM Kavindu Gimhan Zoysa 
wrote:

> Hi all,
>
> Still, I was unable to figure out the reason for the above error. Really
> appreciate your help.
>
> Thank you,
> Kavindu
>
> On Thursday, 24 June 2021 at 12:06:32 UTC+5:30 Kavindu Gimhan Zoysa wrote:
>
>> Hi all,
>>
>> I have build the gollvm and now I am trying to run it. So I run follwing
>> command against a simple go source code. I am getting below error. Really
>> appreciate your input to solve this issue.
>>
>> command :
>> *./bin/llvm-goc test.go*
>>
>> error:
>> *llvm-goc:
>> /home/kavindu/GIT/llvm-project/llvm/tools/gollvm/driver/Action.cpp:51:
>> const char* gollvm::driver::Action::resultFileSuffix() const: Assertion
>> `false' failed.*
>> *../bin/llvm-goc(+0x2c46a3f)[0x55a113e42a3f]*
>> *../bin/llvm-goc(+0x2c46ad6)[0x55a113e42ad6]*
>> *../bin/llvm-goc(+0x2c44829)[0x55a113e40829]*
>> *../bin/llvm-goc(+0x2c46387)[0x55a113e42387]*
>> */lib/x86_64-linux-gnu/libpthread.so.0(+0x153c0)[0x7f67e0aad3c0]*
>> */lib/x86_64-linux-gnu/libc.so.6(gsignal+0xcb)[0x7f67e056818b]*
>> */lib/x86_64-linux-gnu/libc.so.6(abort+0x12b)[0x7f67e0547859]*
>> */lib/x86_64-linux-gnu/libc.so.6(+0x25729)[0x7f67e0547729]*
>> */lib/x86_64-linux-gnu/libc.so.6(+0x36f36)[0x7f67e0558f36]*
>> *../bin/llvm-goc(+0x827e69)[0x55a111a23e69]*
>> *../bin/llvm-goc(+0x8167d5)[0x55a111a127d5]*
>> *../bin/llvm-goc(+0x81db02)[0x55a111a19b02]*
>> *../bin/llvm-goc(+0x81ddfb)[0x55a111a19dfb]*
>> *../bin/llvm-goc(+0x811cb9)[0x55a111a0dcb9]*
>> */lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0x7f67e05490b3]*
>> *../bin/llvm-goc(+0x81112e)[0x55a111a0d12e]*
>> *PLEASE submit a bug report to https://bugs.llvm.org/
>>  and include the crash backtrace.*
>> *Stack dump:*
>> *0. Program arguments: ../bin/llvm-goc test.go *
>> *Aborted (core dumped)*
>>
>> I have build gollvm using exact commits as shown here.
>> https://groups.google.com/g/golang-nuts/c/E770QGuKkpU/m/sJFuarbrBQAJ
>>
>> Thank you,
>> Kavindu
>>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/5a73b285-1252-400a-9259-20b2d7f68e5cn%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BUr55He8a3J9yWsjZnuRDAZOeKZGqZo3RjC1%2BTB%3De-P%3Dt1MDw%40mail.gmail.com.

Re: [go-nuts] Hi all,

['Than McIntosh' via golang-nuts]

This change has been submitted; if you update your gollvmn repo you should
be able to build cleanly now.

Thanks, Than


On Thu, Jun 24, 2021 at 9:22 AM Than McIntosh  wrote:

> Hello,
>
> I sent a CL to fix this problem:
> https://go-review.googlesource.com/c/gollvm/+/330609. I'll let you know
> when it is submitted.
>
> Thanks, Than
>
>
> On Wed, Jun 23, 2021 at 5:30 PM Than McIntosh  wrote:
>
>> Hi,
>>
>> I'll take a look -- stay tuned.
>>
>> Than
>>
>>
>> On Wed, Jun 23, 2021 at 3:04 PM Kavindu Gimhan Zoysa <
>> kavindu...@gmail.com> wrote:
>>
>>> By following `gollvm` document I started to build it. But I got this
>>> error in the middle of the build process.
>>>
>>> */home/kavindu/GIT/llvm-project/llvm/tools/gollvm/passes/GC.cpp:20:10:
>>> fatal error: llvm/CodeGen/GCStrategy.h: No such file or directory*
>>> *   20 | #include "llvm/CodeGen/GCStrategy.h"*
>>> *  |  ^~~*
>>> *compilation terminated.*
>>>
>>> Could you please help me to solve this issue.
>>> I have used the llvm-project's main branch to build this. Do we need to
>>> strict to a special commit in llvm-project to build gollvm?
>>>
>>> I am building this on ubuntu 20.04
>>>
>>> Thank you,
>>> Kavindu
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to golang-nuts+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/c33bd416-c366-4fb0-a966-17553ffd0a76n%40googlegroups.com
>>> 
>>> .
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BUr55E3rfJ2AvMdy9JOG%3DK1yp7L1GT9xdd1KrF4zqn-uJ9otg%40mail.gmail.com.

Re: [go-nuts] How to get the executable file from LLVM IR generated by gollvm

['Than McIntosh' via golang-nuts]

Hello,

What you're talking about is not something that's currently supported by
gollvm.

The way that the gollvm driver code is structured, each input file is
placed into one of three categories: Go source files, assembly files, and
"everything else".  Files that fall into the third category are passed
directly to the linker, which is why you are seeing linker errors above.

It seems possible that someone could write driver code that could read and
parse the *.ll file (converting it into LLVM IR) and then pass that on to
the back end (along with the IR from compile Go files), but this feature
doesn't currently exist at the moment.

Thanks, Than



On Thu, Jun 24, 2021 at 10:33 AM cy lee <190121042...@gmail.com> wrote:

> Hi,
>
> I get the .ll files from gollvm, and I know there is no way to get
> executable file by lli, but whether there are other ways can do this?
>
> here is the simple go code, *hello.go*
>
>
>
> *package mainimport "fmt"func main() { *
> *fmt.Println("hello world") *
> *}*
>
> Using commands as following, we can get .ll file
>
> *llvm-goc -S -emit-llvm hello.go -o hello.ll*
>
> and I try *llvm-goc hello.ll -o hello* , getting error
>
> */usr/bin/ld.gold：错误： hello.ll:1:14: invalid character*
> */usr/bin/ld.gold：错误： hello.ll:1:14: syntax error, unexpected $end*
> */usr/bin/ld.gold：错误： hello.ll: not an object or archive*
>
> Best wishes
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/4e480562-549c-496b-961c-589b7ee22b8fn%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BUr55Ez4WcrsxnGyqyqzYao-iWZTRc-4fdAzLEzsJrZo0dJ5w%40mail.gmail.com.

Re: [go-nuts] How does stack overflow handles in gollvm

['Than McIntosh' via golang-nuts]

Hello,

If you go into your LLVM IR dump and look at the place where the function
is defined, you'll see a reference to an attribute set, e.g.

  define void @main.foo(i8* nest %nest.1) #0 !dbg !16 {

Here "#0" refers to this attribute set (appearing later in the dump):

attributes #0 = { "disable-tail-calls"="true" "frame-pointer"="none"
"null-pointer-is-valid"="true" "split-stack" "target-cpu"="x86-64"
"target-features"="+cx8,+fxsr,+mmx,+sse,+sse2,+x87" }

One of these attributes is "split-stack". When this attribute is set, the
LLVM back end will emit a stack check in the prolog with a call to expand
the stack if needed.

You can find this code at

https://github.com/llvm/llvm-project/blob/25bb61649085c0a6e66630bbffe7faa54cd67829/llvm/lib/CodeGen/PrologEpilogInserter.cpp#L1128

Hope this helps.

Thanks, Than

On Wed, Jun 23, 2021 at 11:11 PM Kavindu Gimhan Zoysa 
wrote:

> Hi Kurtis,
>
> Thank you for your input.
>
> I am searching how do languages handle stack overflow. Languages like
> rust, handle this by catching SIGSEGV. In golang, as I found, it was
> handled by increasing the stack[1], [2] (Sorry if my terms are wrong). I
> have generated object dump(objdump -d) for go source code (just a function
> call) I can see that at the beginning of every function call it checks for
> the stack overflow and try to increase the stack(see //go:nosplit section
> of [2]). I am lloking how does gollvm handle this.
>
> *004871a0 :*
> *  4871a0: 64 48 8b 0c 25 f8 ff mov%fs:0xfff8,%rcx*
> *  4871a7: ff ff *
> *  4871a9: 48 8d 44 24 f8lea-0x8(%rsp),%rax*
> *  4871ae: 48 3b 41 10  cmp0x10(%rcx),%rax*
> *  4871b2: 0f 86 e1 00 00 00jbe487299 *
> **
> *  487299: e8 62 80 fc ffcallq  44f300
> *
> *  48729e: e9 fd fe ff ffjmpq   4871a0 *
>
> [1]:
> https://github.com/golang/go/blob/02ab8d1a1dc82ce019969221313bfa28911f54a1/src/runtime/stack.go#L28
> [2]: https://dave.cheney.net/2018/01/08/gos-hidden-pragmas
> On Thursday, 24 June 2021 at 08:17:33 UTC+5:30 Kurtis Rader wrote:
>
>> This might be an XY Problem , or your question
>> simply needs more context. Your sample program is an example of infinite
>> recursion. How that is detected is platform specific. It might be done via
>> a special signal. Or it might be done by a syscall to grow the stack
>> returning an error. So my question is, why are you asking how infinite
>> recursion is handled?
>>
>> On Wed, Jun 23, 2021 at 7:33 PM Kavindu Gimhan Zoysa 
>> wrote:
>>
>>> Hi all,
>>>
>>> *package main*
>>>
>>> *func main() {*
>>> * foo()*
>>> *}*
>>>
>>> *func foo() {*
>>> * a := 5*
>>> * _ = a*
>>> * foo()*
>>> *}*
>>>
>>> I have generated the below llvm ir using the command `./bin/llvm-goc -S
>>> test.go -dump-ir`. I expected there are some llvm intrinsics that have been
>>> used to handle stack overflow. But it is not there. How does gollvm handle
>>> stackoverflow?
>>>
>>> *define void @main.main(i8* nest %nest.0) #0 !dbg !14 {*
>>> *entry:*
>>> *  call void @main.foo(i8* nest undef), !dbg !15*
>>> *  ret void*
>>> *}*
>>>
>>> *define void @main.foo(i8* nest %nest.1) #0 !dbg !16 {*
>>> *entry:*
>>> *  %a = alloca i64, align 8*
>>> *  %0 = bitcast i64* %a to i8**
>>> *  call void @llvm.lifetime.start.p0i8(i64 8, i8* %0)*
>>> *  store i64 5, i64* %a, align 8*
>>> *  call void @llvm.dbg.declare(metadata i64* %a, metadata !17, metadata
>>> !DIExpression()), !dbg !20*
>>> *  %a.ld.0 = load i64, i64* %a, align 8, !dbg !21*
>>> *  call void @main.foo(i8* nest undef), !dbg !22*
>>> *  %1 = bitcast i64* %a to i8**
>>> *  call void @llvm.lifetime.end.p0i8(i64 8, i8* %1)*
>>> *  ret void*
>>> *}*
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to golang-nuts...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/0bbb1347-5ceb-4ed2-9622-cb695d29bc6dn%40googlegroups.com
>>> 
>>> .
>>>
>>
>>
>> --
>> Kurtis Rader
>> Caretaker of the exceptional canines Junior and Hank
>>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/53de3903-83a2-4b31-b73d-4d46504ca28cn%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 

Re: [go-nuts] Hi all,

['Than McIntosh' via golang-nuts]

Hello,

I sent a CL to fix this problem:
https://go-review.googlesource.com/c/gollvm/+/330609. I'll let you know
when it is submitted.

Thanks, Than


On Wed, Jun 23, 2021 at 5:30 PM Than McIntosh  wrote:

> Hi,
>
> I'll take a look -- stay tuned.
>
> Than
>
>
> On Wed, Jun 23, 2021 at 3:04 PM Kavindu Gimhan Zoysa 
> wrote:
>
>> By following `gollvm` document I started to build it. But I got this
>> error in the middle of the build process.
>>
>> */home/kavindu/GIT/llvm-project/llvm/tools/gollvm/passes/GC.cpp:20:10:
>> fatal error: llvm/CodeGen/GCStrategy.h: No such file or directory*
>> *   20 | #include "llvm/CodeGen/GCStrategy.h"*
>> *  |  ^~~*
>> *compilation terminated.*
>>
>> Could you please help me to solve this issue.
>> I have used the llvm-project's main branch to build this. Do we need to
>> strict to a special commit in llvm-project to build gollvm?
>>
>> I am building this on ubuntu 20.04
>>
>> Thank you,
>> Kavindu
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/c33bd416-c366-4fb0-a966-17553ffd0a76n%40googlegroups.com
>> 
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BUr55GXXcgQxqT9HHY4eu7UqqQBMysSsQDFofntDs1VF5r8yg%40mail.gmail.com.

Re: [go-nuts] Hi all,

['Than McIntosh' via golang-nuts]

Hi,

I'll take a look -- stay tuned.

Than


On Wed, Jun 23, 2021 at 3:04 PM Kavindu Gimhan Zoysa 
wrote:

> By following `gollvm` document I started to build it. But I got this error
> in the middle of the build process.
>
> */home/kavindu/GIT/llvm-project/llvm/tools/gollvm/passes/GC.cpp:20:10:
> fatal error: llvm/CodeGen/GCStrategy.h: No such file or directory*
> *   20 | #include "llvm/CodeGen/GCStrategy.h"*
> *  |  ^~~*
> *compilation terminated.*
>
> Could you please help me to solve this issue.
> I have used the llvm-project's main branch to build this. Do we need to
> strict to a special commit in llvm-project to build gollvm?
>
> I am building this on ubuntu 20.04
>
> Thank you,
> Kavindu
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/c33bd416-c366-4fb0-a966-17553ffd0a76n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BUr55GC4Bp3ax9E5ZAzew1rUbnmUSA4DMUkQyKZoLNwVXsVRw%40mail.gmail.com.

Re: [go-nuts] How to compile a go program which uses cgo to llvm IR？

['Than McIntosh' via golang-nuts]

Hello,

As described in https://go.googlesource.com/gollvm/#seetheir, you will
generally want to run "go build" in order to see the correct invocation of
llvm-goc for your use case.

In your case (building a Go file that uses CGO), there is a lot happening
"under the hood" when you do the build -- it's not a single compiler
invocation.

I recommend that you try the following:

 go build -x -work somecgo.go 1> err.txt 2>&1

then take a look at the commands that "go build" is executing to carry out
the build.

You'll first see the invocation of the "cgo" tool, something like this

TERM='dumb' CGO_LDFLAGS='"-g" "-O2"' /x/gollvm-install/tools/cgo -objdir
./go-build3209048615/b001/ -importpath command-line-arguments -gccgo -- -I
./go-build3209048615/b001/ -g -O2 -fsplit-stack ./somecgo.go

The cgo tool analyzes the Go source file and emits new boilerplate / glue
files (both C files and Go files) needed to connect up the two chunks of
code in the file (the C chunk and the Go chunk).

Next you'll see more invocations of the C and Go compilers, e.g. things like

TERM='dumb' /usr/bin/clang-10 -I /tmp -fPIC -m64 -pthread
-fno-caret-diagnostics -Qunused-arguments -fmessage-length=0
-fdebug-prefix-map=$WORK/b001=/tmp/go-build -gno-record-gcc-switches
-funwind-tables -I ./ -g -O2 -fsplit-stack -o ./_x002.o -c somecgo.cgo2.c

and

/x/gollvm-install/bin/llvm-goc -c -O2 -g -m64
-fdebug-prefix-map=$WORK=/tmp/go-build -gno-record-gcc-switches
-fgo-relative-import-path=_/tmp -o ./go-build3209048615/b001/_go_.o -I
./go-build3209048615/b001/_importcfgroot_
./go-build3209048615/b001/_cgo_gotypes.go
./go-build3209048615/b001/somecgo.cgo1.go
./go-build3209048615/b001/_gomod_.go

to generate objects that feed into the final link.

If you want to collect the LLVM IR, you'll need to capture and replay all
of these compilations with the appropriate compiler options (e.g.
"-emit-llvm") and capture the results.

Hope this helps.

Than


On Thu, Jun 10, 2021 at 2:27 AM Peng Deng  wrote:

> Hi, I have the following program
>
> package main
>
> /*
> #include 
>
> static void SayHello(const char* s) {
> puts(s);
> }
> */
> import "C"
>
> func main() {
> C.SayHello(C.CString("Hello, World\n"))
> }
>
> I want to compile this program to LLVM IR with gollvm, the compilation
> instruction is as follows：
>
> llvm-goc -emit-llvm -c -O0 goc.go -o goc.bc
>
> The errors are as follows:
>
> goc.go:10:9: error: import file 'C' not found
> goc.go:13:5: error: reference to undefined name 'C'
> goc.go:13:16: error: reference to undefined name 'C'
>
> What's wrong with my compilation instruction? How could I compile this
> program to LLVM IR?
>
> I would appreciate it if someone could help me.
>
> Thank you!
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/614dface-3e06-4050-8ea2-bf1ffd0c5349n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BUr55ErDC%2BBU-Pm3740FgD-dFBxu7eVLFgKGsyd880m59DHkA%40mail.gmail.com.

Re: [go-nuts] gollvm: LLVM11-compatible version

['Than McIntosh' via golang-nuts]

Try this config for LLVM 11:

LLVM: 43ff75f2c3feef64f9d73328230d34dac8832a91
gollvm: 44a7a475cfd3b871b7a5a0941b8ab1ea9d489adc
gofrontend: be0d2cc2df9f98d967c242594838f86362dae2e7
libbacktrace: 5a99ff7fed66b8ea8f09c9805c138524a7035ece
libffi: 737d4faa00d681b4c758057f67e1a02d813d01c2

That seems to work for me.

Than


On Thu, May 13, 2021 at 8:38 AM Khanh TN  wrote:

> Hi Than,
> The LLVM commit is 43ff75f2c3feef64f9d73328230d34dac8832a91
> It has tag llvmorg-11.0.1
>
> Khanh
>
> On Thursday, May 13, 2021 at 6:46:04 PM UTC+8 th...@google.com wrote:
>
>> What is the SHA in LLVM git corresponding to the official LLVM 11
>> release?
>>
>> Than
>>
>>
>> On Thu, May 13, 2021 at 5:54 AM Khanh TN  wrote:
>>
>>> Hi, I am upgrading to LLVM11, how can I run LLVM11-compatible gollvm?
>>> What are the commits of LLVM, gollvm and related libs should I checkout?
>>>
>>> Thanks!
>>>
>>> Regards,
>>> Khanh
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to golang-nuts...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/d8148f4c-d66f-4d5b-a685-f15bb978edc1n%40googlegroups.com
>>> 
>>> .
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/e9bf1506-7e02-42b4-abf8-fc935f580142n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BUr55HeU2ij3%2B4owVekx3i6qVe43b6fULJPdBVF2Ec9ELtbJw%40mail.gmail.com.

Re: [go-nuts] gollvm: LLVM11-compatible version

['Than McIntosh' via golang-nuts]

What is the SHA in LLVM git corresponding to the official LLVM 11 release?

Than


On Thu, May 13, 2021 at 5:54 AM Khanh TN  wrote:

> Hi, I am upgrading to LLVM11, how can I run LLVM11-compatible gollvm? What
> are the commits of LLVM, gollvm and related libs should I checkout?
>
> Thanks!
>
> Regards,
> Khanh
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/d8148f4c-d66f-4d5b-a685-f15bb978edc1n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BUr55EhMNfWgnfU_kVgapW9O5uYL9f91TME77xOo%3D34B5WtHg%40mail.gmail.com.

Re: [go-nuts] how gollvm produces a project llvm-ir

['Than McIntosh' via golang-nuts]

Hi,

I looked over the gllvm sources, looks interesting. There is no equivalent
for gollvm, someone would need to contribute it. I don't see any
fundamental reason why it would not work, but I am sure there would be
challenges and wrinkles.

One thing to note is that gllvm is emitteding bitcode (*.bc) files, not
LLVM IR dumps (*.ll).

Thanks, Than


On Mon, May 10, 2021 at 9:09 AM ZHOU PERTER  wrote:

> Hi Than,
> Thanks for reply
> For C or C++ code ,there is a tool wllvm
>  and go version gllvm
>  that can building whole-program
> llvm-ir,so i wonder is there any same tool in gollvm
> PETER
>
> 在2021年5月10日星期一 UTC+8 下午8:29:53 写道：
>
>> Hi,
>>
>> It wasn't clear from your email exactly what you are doing or what the
>> error was you encountered (grepping in the gollvm/LLVM sources didn't turn
>> up any error code similar to "unable to locate ParamAttr enum"), but I
>> think it is safe to say that this isn't a supported use case for gollvm, at
>> least I don't know of anyone who is doing this sort of thing already.
>>
>> Generating a *.ll IR file for each translation unit and then reading them
>> all together sounds difficult, seems as though you would need some sort of
>> very strong type unification in order to match up types that are
>> common/shared among translation units. Have you tried doing this on C code,
>> for example?
>>
>> Thanks, Than
>>
>>
>>
>>
>> On Mon, May 10, 2021 at 8:09 AM ZHOU PERTER  wrote:
>>
>>> Hi,
>>> i want to use gollvm to produces a project llvm-ir
>>> i use `go build -work -x . 1> transcript.txt 2>&1` and `egrep
>>> '(WORK=|llvm-goc -c)' transcript.txt`
>>> to ever `llvm-goc -c` command add `-S -emit-llvm` to produces .ll for
>>> each .go file
>>> then i use https://github.com/llir/llvm to transfer llvm ir to go
>>> build-in struct,but llir only parse one file
>>> for simple file it's ok
>>> ```
>>> package main
>>> import (
>>> "fmt"
>>> )
>>> func main(){
>>> a := "hello_world"
>>> fmt.Println(a)
>>> }
>>> but for multiple packages project the error `unable to locate ParamAttr
>>> enum corresponding to "noundef"` occur when i only provide main.ll。
>>> any way to merger mutli .ll to one .ll or other method so that  i can do
>>> multiple packages project data flow analysis?
>>> Thankss,
>>> PERTER
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to golang-nuts...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/2c329707-bc0f-4603-9e98-199102280cecn%40googlegroups.com
>>> 
>>> .
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/1f07839c-164b-4d9b-a19b-2fae422b786fn%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BUr55F4JjybJLPjOdaJqWUeDLJake_jr9%3DLaBXK_hR9F-BKkQ%40mail.gmail.com.

Re: [go-nuts] how gollvm produces a project llvm-ir

['Than McIntosh' via golang-nuts]

Hi,

It wasn't clear from your email exactly what you are doing or what the
error was you encountered (grepping in the gollvm/LLVM sources didn't turn
up any error code similar to "unable to locate ParamAttr enum"), but I
think it is safe to say that this isn't a supported use case for gollvm, at
least I don't know of anyone who is doing this sort of thing already.

Generating a *.ll IR file for each translation unit and then reading them
all together sounds difficult, seems as though you would need some sort of
very strong type unification in order to match up types that are
common/shared among translation units. Have you tried doing this on C code,
for example?

Thanks, Than




On Mon, May 10, 2021 at 8:09 AM ZHOU PERTER  wrote:

> Hi,
> i want to use gollvm to produces a project llvm-ir
> i use `go build -work -x . 1> transcript.txt 2>&1` and `egrep
> '(WORK=|llvm-goc -c)' transcript.txt`
> to ever `llvm-goc -c` command add `-S -emit-llvm` to produces .ll for each
> .go file
> then i use https://github.com/llir/llvm to transfer llvm ir to go
> build-in struct,but llir only parse one file
> for simple file it's ok
> ```
> package main
> import (
> "fmt"
> )
> func main(){
> a := "hello_world"
> fmt.Println(a)
> }
> but for multiple packages project the error `unable to locate ParamAttr
> enum corresponding to "noundef"` occur when i only provide main.ll。
> any way to merger mutli .ll to one .ll or other method so that  i can do 
> multiple
> packages project data flow analysis?
> Thankss,
> PERTER
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/2c329707-bc0f-4603-9e98-199102280cecn%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BUr55EHfONN3HJEf1CnvhQpC712dJKknkrtcVrXJG6tuwu%2B9A%40mail.gmail.com.

Re: [go-nuts] gollvm: sys/unix error with LLVM10

['Than McIntosh' via golang-nuts]

Hi,

I think what you are seeing is basically a consequence of building an older
version of gollvm -- the version you are building doesn't include newer bug
fixes in the gofrontend version of the go command.  The fix you need is in
a gofrontend commit ( c948c2d770122932a05b62f653efa2c51f72d3ae ) that dates
to fall of 2020. The older version of gofrontend you are picking up doesn't
include this fix.

Not sure if there is an easy workaround here-- when building older versions
of the tools you have to be prepared for this sort of thing. I am sure that
there are LLVM bugs fixed in version 11 that are still present in V10, for
example.

Thanks, Than


On Wed, May 5, 2021 at 8:13 AM Khanh TN  wrote:

> Hi, I'm building a tool to analyze the LLVM bitcode of some Go code with
> gollvm.
> We are currently running LLVM10. We will migrate to LLVM11/12 but not sure
> when.
> I followed Than's instruction to build LLVM10-compatible gollvm from
> https://groups.google.com/g/golang-nuts/c/dMZ7vk_Rjzw/m/b1zYDOxLAAAJ
>
> It worked out great until recently. Code that imports
> golang.org/x/sys/unix will cause errors when "go build". I looked around
> and found out the error message is the same as in
> https://github.com/mainflux/coap-cli/issues/3 to the line number of
> gccgo.go.
>
> A suggested fix is getting CGO_ENABLED=1 but "go env" shows CGO_ENABLED=1
> and "set CGO_ENABLED=1" does not help.
>
> The latest gollvm commit works fine though but it requires LLVM13.
>
> Is there any known fix or workaround for my situation? Should I set
> CGO_ENABLED somewhere else?
>
> Thanks,
> Khanh
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/a92eb44d-73c6-43dd-9f1a-551b06589a78n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BUr55EWG28J6g73LrK5jWON7cNDwYrSo36LYpuXm4wGovncMA%40mail.gmail.com.

Re: [go-nuts] Building gollvm fails on the latest commit

['Than McIntosh' via golang-nuts]

Hi again,

Not quite sure what you are asking--

If you want to generated LLVM bitcode and then use that with your version
10 llvm tools, then you'll either need to build a version-10 compatible
gollvm, or you'll need to upgrade the LLVM used by your tools/project.

You can try building a V10-compatible gollvm by checking out old versions
of the various git repos in your work area. These sha's should give you a
working V10 gollvm:

# This is the llvm 10.0.1 final git tag:
LLVM: ef32c611aa214dea855364efd7ba451ec5ec3f74

gollvm: ad0491f483d17893a2439bdb63d0f94124965549

gofrontend: 85641a0f26061f7c98db42a2adb3250c07ce504e

libffi: 737d4faa00d681b4c758057f67e1a02d813d01c2

libbacktrace: 5a99ff7fed66b8ea8f09c9805c138524a7035ece


Cheers, Than

On Wed, Apr 14, 2021 at 11:42 AM Khanh TN  wrote:

> Hi Ian,
> My project is currently running on LLVM10.
> If I want to use gollvm, do I just have to upgrade to the latest commits?
> Thanks
> Khanh
>
> On Wednesday, April 14, 2021 at 11:08:36 PM UTC+8 Khanh TN wrote:
>
>> Thanks,
>> I see it's hard to keep syncing with LLVM. They have new commits every
>> minute
>>
>> Khanh
>>
>> On Wednesday, April 14, 2021 at 10:53:13 PM UTC+8 th...@google.com wrote:
>>
>>> OK, I checked in https://go-review.googlesource.com/c/gollvm/+/310069,
>>> should be resolved now. Thanks for reporting.
>>>
>>> On Tue, Apr 13, 2021 at 7:30 PM Than McIntosh  wrote:
>>>
 Thanks for reporting. I'll look into sending a CL.

 Cheers, Than


 On Tue, Apr 13, 2021 at 6:09 PM Khanh TN  wrote:

> Hi, I'm building gollvm with both gollvm and LLVM on the latest commit.
> It fails and the error reads:
> [..]/llvm-project/llvm/tools/gollvm/passes/GoNilChecks.cpp:363:23:
> error: ‘NoAlias’ was not declared in this scope
>if (AAResult != NoAlias)
>^~~
> [..]/llvm-project/llvm/tools/gollvm/passes/GoNilChecks.cpp:363:23:
> note: suggested alternative: ‘AR_NoAlias’
>
> Can you guys check? Sorry if I'm spamming about gollvm lately.
> Thanks!
> Khanh
>
> --
> You received this message because you are subscribed to the Google
> Groups "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to golang-nuts...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/de629758-4d44-4348-a506-1f2f6404b5b0n%40googlegroups.com
> 
> .
>
 --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/6c371d0f-eea1-4098-999a-3f2126cdb602n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BUr55EK_Rn8FOXdJG%2BXGWQBrmej88mYRkfed%2BmNqw9dnpyBLQ%40mail.gmail.com.

Re: [go-nuts] Building gollvm fails on the latest commit

['Than McIntosh' via golang-nuts]

OK, I checked in https://go-review.googlesource.com/c/gollvm/+/310069,
should be resolved now. Thanks for reporting.

On Tue, Apr 13, 2021 at 7:30 PM Than McIntosh  wrote:

> Thanks for reporting. I'll look into sending a CL.
>
> Cheers, Than
>
>
> On Tue, Apr 13, 2021 at 6:09 PM Khanh TN  wrote:
>
>> Hi, I'm building gollvm with both gollvm and LLVM on the latest commit.
>> It fails and the error reads:
>> [..]/llvm-project/llvm/tools/gollvm/passes/GoNilChecks.cpp:363:23: error:
>> ‘NoAlias’ was not declared in this scope
>>if (AAResult != NoAlias)
>>^~~
>> [..]/llvm-project/llvm/tools/gollvm/passes/GoNilChecks.cpp:363:23: note:
>> suggested alternative: ‘AR_NoAlias’
>>
>> Can you guys check? Sorry if I'm spamming about gollvm lately.
>> Thanks!
>> Khanh
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/de629758-4d44-4348-a506-1f2f6404b5b0n%40googlegroups.com
>> 
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BUr55GhbdumdzM8Ka-rUCE51B%3D1p44pFQnPa0rjVtibwWoZcg%40mail.gmail.com.

Re: [go-nuts] Building gollvm fails on the latest commit

['Than McIntosh' via golang-nuts]

Thanks for reporting. I'll look into sending a CL.

Cheers, Than


On Tue, Apr 13, 2021 at 6:09 PM Khanh TN  wrote:

> Hi, I'm building gollvm with both gollvm and LLVM on the latest commit.
> It fails and the error reads:
> [..]/llvm-project/llvm/tools/gollvm/passes/GoNilChecks.cpp:363:23: error:
> ‘NoAlias’ was not declared in this scope
>if (AAResult != NoAlias)
>^~~
> [..]/llvm-project/llvm/tools/gollvm/passes/GoNilChecks.cpp:363:23: note:
> suggested alternative: ‘AR_NoAlias’
>
> Can you guys check? Sorry if I'm spamming about gollvm lately.
> Thanks!
> Khanh
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/de629758-4d44-4348-a506-1f2f6404b5b0n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BUr55EGVTM6Vi612%3DaVX1rgHbidJipm2campe%3DCtVYY61V7zA%40mail.gmail.com.

Re: [go-nuts] Gollvm produces bad LLVM IR

['Than McIntosh' via golang-nuts]

Hi,

At the moment gollvm does not put out releases per se, meaning that really
the only thing that is advertised as working is the current LLVM tip plus
the current gollvm tip at a given moment in time.

If you wanted to create a version of gollvm for an older LLVM release (ex:
LLVM 10), you would need to look at the date that LLVM was released, then
for each of the sub-repos (gollvm itself, /libgo/libbacktrace,
/libgo/libffi, /gofrontend) you'd need to locate a git
commit close to that date. Or something to this effect.

Can you tell me a bit more about your use case? Why not just use the most
recent version of gollvm (e.g. tip)?

Thanks, Than


On Mon, Apr 12, 2021 at 11:51 AM Khanh TN  wrote:

> Hi Than,
> I'm trying to build gollvm with different versions of llvm: LLVM8, 10, 11
> and 13git. It looks like only 13git works.
> -emit-llvm has some issues. The produced *.ll and *.bc LLVM bitcode can
> only be opened with some of LLVM versions, and which version is quite
> random to me.
> Is there a manual on which version of LLVM should I build gollvm with and
> which version is the bitcode that -emit-llvm produces?
> Thanks,
> Khanh
>
> On Thursday, April 8, 2021 at 10:55:16 PM UTC+8 Khanh TN wrote:
>
>> Thanks. Looks like I need everything, including llc at LLVM11. I will
>> stick with LLVM11.
>> I assume gollvm will match with whatever LLVM version is current, like,
>> update to match LLVM12 when LLVM12 is out?
>>
>> Khanh
>> On Thursday, April 8, 2021 at 10:40:19 PM UTC+8 th...@google.com wrote:
>>
>>> >It outputs a hello.ll file. LLVM11 can process it but 10.0.1 and 13git
>>> cannot
>>> >Would love to hear your feedback. Maybe I need the exact LLVM version
>>> that gollvm is targeting?
>>>
>>> Yes, that is correct. The LLVM IR dump format (*.ll files) tends to
>>> change over time and from release to release, it isn't intended or designed
>>> to be stable.
>>>
>>> One way to insure that you have a conformant version of llc/lli (or
>>> equivalent) is just to build then in the same build directory where you
>>> built llvm.
>>>
>>> E.g. after "ninja gollvm" you can then try "ninja llc", then use the
>>> freshly built llc binary (found in ./bin) for your work.
>>>
>>> Thanks, Than
>>>
>>>
>>>
>>> On Thu, Apr 8, 2021 at 10:00 AM Khanh TN  wrote:
>>>
 Hi,
 Thanks for your reply.
 It's a bit weird.
 I tried LLVM10.0.1 and the LLVM13 built from github along with gollvm,
 both did not work.
 However, I just tried LLVM11 and it worked. I haven't tried LLVM12. It
 looks like different LLVM version has different syntax?

 The Go code I tried is simplest:
 I have 1 file hello.go:

 package main
 import(
"fmt"
 )

 func main() {
 fmt.Println("Hello, playground")
 }

 As instructed in "How do I see the LLVM IR generated by gollvm?" on
 https://go.googlesource.com/gollvm , I ran
 > go build -work -x hello.go 1> transcript.txt 2>&1
 > egrep '(WORK=|llvm-goc -c)' transcript.txt
 WORK=/tmp/go-build903363323
 [...]
 > WORK=/tmp/go-build903363323
 >[..change output to -o hello.ll; add -S -emit-llvm]

 It outputs a hello.ll file. LLVM11 can process it but 10.0.1 and 13git
 cannot
 Would love to hear your feedback. Maybe I need the exact LLVM version
 that gollvm is targeting?

 Khanh
 On Thursday, April 8, 2021 at 7:07:13 PM UTC+8 th...@google.com wrote:

> Hi,
>
> Can you be a bit more specific, e.g. what Go code you compiler and
> what error you saw? It would also be helpful to know what version of
> lli/llc you were using.
>
> Thanks, Than
>
>
> On Thu, Apr 8, 2021 at 2:33 AM Khanh TN  wrote:
>
>> Hi,
>> I'm following this page https://go.googlesource.com/gollvm to
>> compile Go code the LLVM way.
>> I'm at the step "How do I see the LLVM IR generated by gollvm?" of
>> the page. I'm doing exactly as the instruction. Gollvm produces a .ll 
>> file
>> but the file has bad syntax. Running llvm-as (or llc, lli) on the 
>> generated
>> .ll file gives error (I think its syntax error)
>> Can anyone check this out?
>>
>> Thankss,
>>
>> Khanh
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it,
>> send an email to golang-nuts...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/e21d46ff-d151-46fc-ac1d-5da2a153a9fdn%40googlegroups.com
>> 
>> .
>>
> --
 You received this message because you are subscribed to the Google
 Groups "golang-nuts" group.
 To unsubscribe from this group and stop receiving emails 

Re: [go-nuts] Gollvm produces bad LLVM IR

['Than McIntosh' via golang-nuts]

>It outputs a hello.ll file. LLVM11 can process it but 10.0.1 and 13git
cannot
>Would love to hear your feedback. Maybe I need the exact LLVM version that
gollvm is targeting?

Yes, that is correct. The LLVM IR dump format (*.ll files) tends to change
over time and from release to release, it isn't intended or designed to be
stable.

One way to insure that you have a conformant version of llc/lli (or
equivalent) is just to build then in the same build directory where you
built llvm.

E.g. after "ninja gollvm" you can then try "ninja llc", then use the
freshly built llc binary (found in ./bin) for your work.

Thanks, Than



On Thu, Apr 8, 2021 at 10:00 AM Khanh TN  wrote:

> Hi,
> Thanks for your reply.
> It's a bit weird.
> I tried LLVM10.0.1 and the LLVM13 built from github along with gollvm,
> both did not work.
> However, I just tried LLVM11 and it worked. I haven't tried LLVM12. It
> looks like different LLVM version has different syntax?
>
> The Go code I tried is simplest:
> I have 1 file hello.go:
>
> package main
> import(
>"fmt"
> )
>
> func main() {
> fmt.Println("Hello, playground")
> }
>
> As instructed in "How do I see the LLVM IR generated by gollvm?" on
> https://go.googlesource.com/gollvm , I ran
> > go build -work -x hello.go 1> transcript.txt 2>&1
> > egrep '(WORK=|llvm-goc -c)' transcript.txt
> WORK=/tmp/go-build903363323
> [...]
> > WORK=/tmp/go-build903363323
> >[..change output to -o hello.ll; add -S -emit-llvm]
>
> It outputs a hello.ll file. LLVM11 can process it but 10.0.1 and 13git
> cannot
> Would love to hear your feedback. Maybe I need the exact LLVM version that
> gollvm is targeting?
>
> Khanh
> On Thursday, April 8, 2021 at 7:07:13 PM UTC+8 th...@google.com wrote:
>
>> Hi,
>>
>> Can you be a bit more specific, e.g. what Go code you compiler and what
>> error you saw? It would also be helpful to know what version of lli/llc you
>> were using.
>>
>> Thanks, Than
>>
>>
>> On Thu, Apr 8, 2021 at 2:33 AM Khanh TN  wrote:
>>
>>> Hi,
>>> I'm following this page https://go.googlesource.com/gollvm to compile
>>> Go code the LLVM way.
>>> I'm at the step "How do I see the LLVM IR generated by gollvm?" of the
>>> page. I'm doing exactly as the instruction. Gollvm produces a .ll file but
>>> the file has bad syntax. Running llvm-as (or llc, lli) on the generated .ll
>>> file gives error (I think its syntax error)
>>> Can anyone check this out?
>>>
>>> Thankss,
>>>
>>> Khanh
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to golang-nuts...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/e21d46ff-d151-46fc-ac1d-5da2a153a9fdn%40googlegroups.com
>>> 
>>> .
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/6539ccc0-3a3f-4e40-a268-e45593fc29d1n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BUr55Ex5N4o%3Dc7ft-K6RhiOsftdai-RrZ64ZVTwi-iu9HQanA%40mail.gmail.com.

Re: [go-nuts] Gollvm produces bad LLVM IR

['Than McIntosh' via golang-nuts]

Hi,

Can you be a bit more specific, e.g. what Go code you compiler and what
error you saw? It would also be helpful to know what version of lli/llc you
were using.

Thanks, Than


On Thu, Apr 8, 2021 at 2:33 AM Khanh TN  wrote:

> Hi,
> I'm following this page https://go.googlesource.com/gollvm to compile Go
> code the LLVM way.
> I'm at the step "How do I see the LLVM IR generated by gollvm?" of the
> page. I'm doing exactly as the instruction. Gollvm produces a .ll file but
> the file has bad syntax. Running llvm-as (or llc, lli) on the generated .ll
> file gives error (I think its syntax error)
> Can anyone check this out?
>
> Thankss,
>
> Khanh
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/e21d46ff-d151-46fc-ac1d-5da2a153a9fdn%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BUr55Gd%3Do4KQzsx-sK-PqK4H7nvBtJ%3DeTLFsPsFtH7VFoE1sA%40mail.gmail.com.

Re: [go-nuts] gollvm hasn't a good support to reflect and pthread?

['Than McIntosh' via golang-nuts]

Thank you @Ugorji Nwoke   , I appreciate your going the
extra mile to include gollvm in your testing.

Cheers, Than


On Tue, Mar 30, 2021 at 11:17 AM Ugorji Nwoke  wrote:

> Ugorji here - author of the github.com/ugorji/go/codec
>  package.
>
> The notes below are for folks that are interested in why we use unsafe,
> and how we mitigate concerns around it.
>
> As Peter mentioned above, you can pass the build tag "codec.safe" to
> bypass using unsafe code where we try to reach deeper into the runtime
> implementation to optimize.
>
> I have been supporting gccgo for a while now, but never tested with
> gollvm, as it has not been released at this time. I built a gollvm version
> yesterday (from source) and tested it, and made some changes (see here
> 
> and here
> )
> so that gollvm will work in the default (high-performance) mode. I plan to
> cut a new release v1.2.5 sometime this week with those changes.
>
> For those who care about why we support unsafe and dig into the runtime
> internals, please read below.
>
> To illustrate the benefit, look at unsafe vs codec.safe benchmark results
> below:
> ```
>  tags: "" (default high-performance mode using unsafe carefully) 
> Benchmark__Json___Encode-86921 152808 ns/op   24 B/op
>  1 allocs/op
> Benchmark__Json___Encode-85622 197863 ns/op10048 B/op
>381 allocs/op
>
>  tags: "codec.safe" 
> Benchmark__Json___Decode-82587 415595 ns/op71878 B/op
>592 allocs/op
> Benchmark__Json___Decode-82167 478122 ns/op96812 B/op
>   1456 allocs/op
>
>  tags: x generated 
> Benchmark__Json___Encode-88694 120519 ns/op 1528 B/op
>  6 allocs/op
> Benchmark__Json___Decode-82960 349320 ns/op70469 B/op
>589 allocs/op
> ```
>
> This benchmarks show that using unsafe carefully can cut down allocations
> dramatically. Encoding allocation goes from 381 to 1, while decoding goes
> from 1456 to 592. Those numbers using unsafe rival the allocation numbers
> that we get using code-generation (as seen above), and the run time starts
> to trend within 25% of the code-generation numbers, and 25% better than the
> non-unsafe run time.
>
> We limited the surface area that is exposed to unsafe (basically 1 file,
> helper_unsafe.go, with some variant for gccgo/gollvm where some linkname
> references do not exist or work differently), so we can quickly edit the
> code and know where bugs are coming from. Many other packages that try to
> optimize json/cbor/msgpack encoding and decoding use some variation of the
> same ideas here.
>
> I test the code  for the last 5 go releases on each github checkin, via
> travis CI. I also run with the standard compiler and gccgo locally before
> cutting a release. I have now added gollvm to my pre-release validation
> script, so it is validated before I cut the release. Caveat: I test with
> the installed versions of gccgo from ubuntu, and locally built gollvm.
> Since gollvm is not released yet, the version I test with may be old
> (building gollvm takes roughly 1 hour on my computer).
>
> If you see any further issues, please file a bug and I will jump on it:
> https://github.com/ugorji/go/issues/new
>
> Thanks.
> On Monday, March 29, 2021 at 8:32:53 AM UTC-4 peterGo wrote:
>
>> You haven't said whether you followed the "safe" instructions for
>> github.com/ugorji/go/codec to avoid building code/helper_unsafe.go,
>> which uses go:linkname.
>>
>> Package Documentation for github.com/ugorji/go/codec
>> https://github.com/ugorji/go/blob/master/codec/README.md
>>
>> This package will carefully use 'package unsafe' for performance reasons
>> in specific places. You can build without unsafe use by passing the safe or
>> appengine tag i.e. 'go install -tags=codec.safe
>>
>> You can run the tag 'codec.safe' to run tests or build in safe mode. e.g.
>>
>> go test -tags codec.safe -run Json
>> go test -tags "alltests codec.safe" -run Suite
>>
>> Peter
>>
>> On Monday, March 29, 2021 at 3:34:44 AM UTC-4 f011...@gmail.com wrote:
>>
>>> >  go:linkname to refer directly to functions that are defined but not
>>> exported by the standard library.
>>> > This is not supported and is likely to break with any new release. It
>>> evidently breaks with GoLLVM.
>>>
>>> Thanks for your attention, but I tried to write a demo with go:linkname.
>>> In fact, it works well with gollvm...So maybe it is not the exact cause
>>> for the problem
>>>
>>> Herei is my code:
>>>
>>> hello/hello.go
>>> ```
>>> package hello
>>>
>>> import (
>>> "fmt"
>>> _ "unsafe"
>>> )
>>> //go:linkname hellox hello.hellox
>>> func hellox(x string) {
>>> fmt.Println(x)
>>> }
>>> ```
>>>
>>> main.go
>>> ```
>>> package main
>>>
>>> import (
>>> _ 

Re: [go-nuts] gollvm hasn't a good support to reflect and pthread?

['Than McIntosh' via golang-nuts]

Hi,

*>Thanks for your attention, but I tried to write a demo with go:linkname.*
*>In fact, it works well with gollvm...So maybe it is not the exact cause
for the problem*

The problem is not that gollvm fails to implement go:linkname-- the problem
is the way that this package (http://github.com/ugorji/go)  is using
go:linkname.

The Go runtime and standard library has a public, exported API; this sort
of use of go:linkname to reach into the internals of a standard package (in
this case, calling an unexported function) is not supported.

Folks who write such code should understand that it can break at any time
from release to release or across Go implementations.

Than




On Mon, Mar 29, 2021 at 3:35 AM JX Zhang  wrote:

> >  go:linkname to refer directly to functions that are defined but not
> exported by the standard library.
> > This is not supported and is likely to break with any new release. It
> evidently breaks with GoLLVM.
>
> Thanks for your attention, but I tried to write a demo with go:linkname.
> In fact, it works well with gollvm...So maybe it is not the exact cause
> for the problem
>
> Herei is my code:
>
> hello/hello.go
> ```
> package hello
>
> import (
> "fmt"
> _ "unsafe"
> )
> //go:linkname hellox hello.hellox
> func hellox(x string) {
> fmt.Println(x)
> }
> ```
>
> main.go
> ```
> package main
>
> import (
> _ "mypackage/hello"
> _ "unsafe"
> )
>
> //go:linkname hel hello.hellox
> func hel(x string)
>
> func main() {
> hel("aaa")
> //println("")
> }
> ```
>
> 在2021年3月29日星期一 UTC+8 上午12:37:49 写道：
>
>> On Sun, Mar 28, 2021 at 9:28 AM 张嘉熙  wrote:
>> >
>> > For s2-geojson, I meet:
>> > ```
>> > # github.com/pantrif/s2-geojson/cmd/s2-geojson
>> >
>> /home/jx/.cache/go-build/6b/6bd003c99eb0a9e7c6ea6d372307b292ec615c75c28f9b1f696896ae2fb4272b-d(_go_.o):gomodule:function
>> github_0com_1ugorji_1go_1codec.intf2impls.intf2impl: error: undefined
>> reference to 'reflect.unsafe_New'
>> >
>> /home/jx/.cache/go-build/6b/6bd003c99eb0a9e7c6ea6d372307b292ec615c75c28f9b1f696896ae2fb4272b-d(_go_.o):gomodule:function
>> github_0com_1ugorji_1go_1codec.Decoder.interfaceExtConvertAndDecode: error:
>> undefined reference to 'reflect.unsafe_New'
>> > decode.go:509: error: undefined reference to 'reflect.unsafe_New'
>> > decode.go:14935: error: undefined reference to 'reflect.unsafe_New'
>>
>> This is a problem with github.com/ugorji/go. The file
>> code/helper_unsafe.go uses go:linkname to refer directly to functions
>> that are defined but not exported by the standard library. This is
>> not supported and is likely to break with any new release. It
>> evidently breaks with GoLLVM.
>>
>> Ian
>>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/5d763cdf-1147-4abe-aea7-9f6efa39e930n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BUr55H4Q4%2BoztZjm3ZcrsFdQ-gBvy_V9WE%3D-Y3CnoTHWLFuqg%40mail.gmail.com.

Re: [go-nuts] Error running gollvm on Ubuntu 20.04

['Than McIntosh' via golang-nuts]

Thanks Ian, yes, that seems likely. I will look into sending a patch.

Than


On Tue, Mar 9, 2021 at 1:23 PM Ian Lance Taylor  wrote:

> On Tue, Mar 9, 2021 at 9:21 AM Khanh TN  wrote:
> >
> > Hi, I'm a newbie.
> > I built and installed gollvm with instructions from
> https://go.googlesource.com/gollvm
> > The build/installation was successful but it cannot run after installing.
> > The step on the page "Using an installed copy of gollvm" is where the
> error happens. Running "go" gives me this error:
> > symbol lookup error:
> /home/user/another-gollvm-installdir/lib64/libgo.so.13git: undefined
> symbol: runtime.memmove
> > I'm on Ubuntu 20.04, gcc 9.3.0.
> > Anyone has this problem or built gollvm and has the solution for me?
> Also, can anyone replicate this error? (If you have free time, thanks,
> building anything llvm takes lots of time lol) (Should I file an issue on
> github?)
>
> My guess is that the GoLLVM cmake files need to be updated for the
> addition of libgo/runtime/go-memmove.c in
> https://golang.org/cl/294931.
>
> Ian
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BUr55EOHv4brpg0Hesqii-BuucJRE2GpO%2BJKVKLv4Nvnko9QQ%40mail.gmail.com.

Re: [go-nuts] Incompatibility of reflection libraries (reflect versus go-reflect), on json-iterator (Go 1.15.8)

['Than McIntosh' via golang-nuts]

My sense is that developers are using packages like reflect2 for
performance reasons, very often to try to improve JSON
marshalling/unmarshalling speed. These packages tend to bypass the Go type
system using "unsafe" in order to provide reflect-like operations without
the overhead (e.g. allocation) that would be incurred if they used the
regular reflect package in the standard library.

Because these packages are "reaching under the hood" via unsafe, they tend
to be written against a specific implementation (and in fact against a
specific version of a specific implementation).  So probably not surprising
that they do not play well with gccgo/gollvm.

Than


On Fri, Feb 26, 2021 at 10:00 AM Ian Lance Taylor  wrote:

> On Fri, Feb 26, 2021 at 6:11 AM Yan Titarenko
>  wrote:
> >
> > CC'ing to committers.
> >
> > Ian,
> > please provide some advise.
>
> I'm sorry, I don't have anything useful to add beyond what I've already
> said.
>
> I don't know why people are using the reflect2 package.  The package
> does not support gccgo/GoLLVM.  The first step is to understand why
> people use reflect2, and whether we can improve the standard reflect
> package to address whatever problems led to the creation of reflect2.
>
> Ian
>
>
> > On Wed, Feb 24, 2021 at 2:00 PM Yan Titarenko <
> local.tourist.k...@gmail.com> wrote:
> >>
> >> Hi.
> >>
> >> Since there where no comments on
> https://github.com/json-iterator/go/issues/501 - I decided that an open
> discussion (not necessarily on behalf of this project - there could be
> other projects/use cases, which could a cause for contributions, into the
> reflection library).
> >>
> >> I tried to test with Golang 1.15.8. I tried an old version of
> llvm-goc/gollvm - but can re-check, using the latest version of gollvm.
> >> Also hence that one of the checks was done on x86_64 Windows 10.
> >>
> >> It is not clear what kind of patch (and in favor of which engineering
> targets) would be required, yet - so we are not at the point where we could
> excavate OS/arch dependent issues.
> >>
> >> I see a lot of errors like
> >>
> >> ./any.go:259:15: undefined: "github.com/goccy/go-reflect".TypeOfPtr
> >> ./reflect_array.go:36:15: undefined: "github.com/goccy/go-reflect
> ".UnsafeArrayType
> >> .
> >> I tried to do two things: I tried to revert back from reflect2 to
> libgo's reflect - and I tried to use goccy's go-reflect, instead of
> reflect2.
> >> It is interesting that both attempts brought similar errors - but they
> also brought some unique errors.
> >> But nothing that would bring specific practical wage, just case of that.
> >>
> >> Yan
> >>
> >> --
> >> You received this message because you are subscribed to the Google
> Groups "golang-nuts" group.
> >> To unsubscribe from this group and stop receiving emails from it, send
> an email to golang-nuts+unsubscr...@googlegroups.com.
> >> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/ab44891f-eca6-47cb-a4b1-c6292d6015a7n%40googlegroups.com
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAKOQZ8zbyemhzCd_1cEAkrc5FAwcdDOyo%3DxSBNafcA_mTpdYnQ%40mail.gmail.com
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BUr55F65SC1pztoWvsW3GjvCWuGd7vYa-Q7WfKpS1mop1LWwA%40mail.gmail.com.

Re: [go-nuts] Questions Regarding Go 1.15 Dwarf generation

['Than McIntosh' via golang-nuts]

I would second Ian's recommendation to look at the 1.16 code -- a lot has
changed since 1.15.

>>There is a LoadFull function in loader with works with payloads but I
have no idea what function and in what phase the raw data for each symbols
being created and added to payloads. I would appreciate if anyone could
help me in this regard

LoadFull no longer exists in 1.16 -- it was a transitional function used
due to the fact that as of the 1.15 release the linker wasn't completely
converted to a new internal representation.

HTH

Than




On Tue, Feb 23, 2021 at 12:29 PM Mahdi Hosseini 
wrote:

> Thanks for your reply.
> Actually yes, I am looking at the dwarfGenerateDebugSyms function in
> dwarf.go in cmd/lin/internal/ld trying to understand how and when CUs are
> being generated and then added to dwarfp2 specially the header and length
> of each CU.
>
> R,
> Mahdi
>
> On Mon, Feb 22, 2021 at 11:36 PM Ian Lance Taylor  wrote:
>
>> On Mon, Feb 22, 2021 at 12:59 PM m.hos...@gmail.com
>>  wrote:
>> >
>> > I am experimenting with dwarf generation in Go1.15 at the moment and
>> looking into new loader module. I am trying to understand how the data
>> being generated and put into []byte specifically how the loader.payloads
>> item being generated. I couldn't figure it out yet.
>> > There is a LoadFull function in loader with works with payloads but I
>> have no idea what function and in what phase the raw data for each symbols
>> being created and added to payloads. I would appreciate if anyone could
>> help me in this regard.
>>
>> This code is different in 1.16.  I recommend that you look at 1.16.
>>
>> Some DWARF information is generated at compile time and some is
>> generated at link time.  Is there anything specific you are interested
>> in?
>>
>> Ian
>>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAP%3DptTKW0BVjd1gonVREMxSwGnHiSX%2ByungkbatmcfkmK1q0Dg%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BUr55Hxvf0FbeynNdE10V%2BqgkN_XAaN9%3DZJE%3D8%3DgRCmB-srKA%40mail.gmail.com.

Re: [go-nuts] gollvm: meaningless "unsupported llvm::CallingConv::ID"

['Than McIntosh' via golang-nuts]

On Thu, Jan 14, 2021 at 8:38 AM Ivan Serdyuk 
wrote:

> Hi.
>
> I caught the following error:
>
> https://go.googlesource.com/gollvm/+/refs/heads/master/bridge/go-llvm-cabi-oracle.cpp#162
>

Would it help to share the actual error message and compiler invocation?

> Among other things: people has nothing to do with an ID. There is a
> specific list of options:
> https://llvm.org/doxygen/namespacellvm_1_1CallingConv.html
> .
> But providing a human friendly name *with* an ID could have some sense.
>

Not sure what you are saying here.

The line number you cite above indicates that gollvm is being asked to use
a calling convention that is recognized and/or supported by clang/LLVM, but
not supported by gollvm.

Another problem is that this is an intersection with the class, dedicated
> to a specific struct alignment. I have doubts that all (at least - user
> mode, not kernel mode ) calling conventions would assume all possible
> options, for aligning structs/unions. Also there are OS specific issues -
> so it more about OS-convention-alignment triple.
>
> I would propose some re-design, to offer a purpose specific output,
> depending on developer's goals. So the output would help to navigate
> against the next step.
>

?

Again, not sure what you are getting at.

Than

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BUr55FGe0g2Dbf%3DDErxGkcr0uJ-Py85y54P7BmVRKwyhhH8VQ%40mail.gmail.com.

Re: [go-nuts] gollvm: capture-fcn-attributes.go generates the header file with improperly chosen CPU model (i686; yonah)

['Than McIntosh' via golang-nuts]

You can of course run capture-fcn-attributes with an explicit set of
triples, e.g.

 $ ./capture-fcn-attributes -o ../driver/ArchCpusAttrs.h -triples
i686-pc-linux-gnu

which will get you off the ground... but you would not want to check in the
resulting header. The values in ArchCpusAttrs.h have to cover all supported
targets.

Than


On Wed, Jan 6, 2021 at 4:31 PM Ivan Serdyuk 
wrote:

> My current scenario assumes that I have compiled for x86 targets, to run
> Clang on an x86 machine. What should be done if it is not assumed to
> involve any other back-ends, during the build?
>
>
> On Wed, Jan 6, 2021 at 10:27 PM Than McIntosh  wrote:
>
>> Right, that would be expected.   The easiest thing to do is make sure
>> that you're running cmake in your build area with
>>
>>-DLLVM_TARGETS_TO_BUILD="all"
>>
>> then you can build "llc" and "clang" , then update your path so that the
>> freshly built llc/clang are picked up first. Once you have that set up, it
>> should take care of the problem running "llc" from capture-fcn-attributes.
>>
>> Than
>>
>>
>> On Wed, Jan 6, 2021 at 3:14 PM Ivan Serdyuk 
>> wrote:
>>
>>> I think a caught an error:
>>>
>>> $ ./capture-fcn-attributes
 llc run failed: llc: error: : error: unable to get target for
 'aarch64-unknown-linux-gnu', see --version and --triple.

 capture-fcn-attributes: err = exit status 1

>>>
>>> . Hence that I didn't compile Aarch64 back-end, for LLVM:
>>>
>>> $ llc --version
 LLVM (http://llvm.org/):
   LLVM version 12.0.0git
   Optimized build.
   Default target: i686-pc-linux-gnu
   Host CPU: yonah

   Registered Targets:
 x86- 32-bit X86: Pentium-Pro and above
 x86-64 - 64-bit X86: EM64T and AMD64

>>> . So this would not run out-of-the-box.
>>>
>>>
>>>
>>> On Wed, Jan 6, 2021 at 8:21 PM Than McIntosh  wrote:
>>>
 Thanks. The error you're seeing

   "unable to determine target CPU features for target i686-pc-linux-gnu"

 looks as though it's because i686-pc-linux-gnu isn't listed as a target
 in
 driver/ArchCpusAttrs.h.

 From the root of your repo, try

   $ cd tools
   $ go build capture-fcn-attributes.go
   $ ./capture-fcn-attributes -o ../driver/ArchCpusAttrs.h

 and then give the gollvm build another try.

 Thanks, Than

 On Wed, Jan 6, 2021 at 12:53 PM Ivan Serdyuk <
 local.tourist.k...@gmail.com> wrote:

> Here you go:
>
> ~/Desktop/workarea/llvm-project/llvm/tools/gollvm$ git diff
> diff --git a/cmake/modules/AutoGenGo.cmake
> b/cmake/modules/AutoGenGo.cmake
> index 3e3ab83..097a2ad 100644
> --- a/cmake/modules/AutoGenGo.cmake
> +++ b/cmake/modules/AutoGenGo.cmake
> @@ -51,6 +51,17 @@ function(mkversion goos goarch outfile bindir
> srcroot scriptroot)
>  set(pcquantum "1")
>  set(int64align "8")
>  set(minframesize 0)
> +  elseif( ${goarch} STREQUAL "386")
> +# Simply picking up one typical setting
> +# Align with current sets in gofrontend/libgo/goarch.sh
> +set(archfamily "I386")
> +set(bigendian "false")
> +set(cachelinesize "64")
> +set(physpagesize "4096")
> +set(pcquantum "1")
> +set(int64align "4")
> +set(minframesize 4)
> +set(ptrsize 4)
>elseif( ${goarch} STREQUAL "arm64")
>  # Simply picking up one typical setting
>  # Align with current sets in gofrontend/libgo/goarch.sh
> diff --git a/cmake/modules/GoVars.cmake b/cmake/modules/GoVars.cmake
> index ec6f6b2..0cea38a 100644
> --- a/cmake/modules/GoVars.cmake
> +++ b/cmake/modules/GoVars.cmake
> @@ -8,6 +8,9 @@ list(GET lht_components 2 goos)
>  # LLVM's "x86_64" is the same as Go's "amd64".
>  if( ${llarch} STREQUAL "x86_64" )
>set(goarch "amd64")
> +# For i386/i686
> +elseif( ${llarch} STREQUAL "i686" )
> +  set(goarch "386")
>  # LLVM's "aarch64" is the same as Go's "arm64".
>  elseif( ${llarch} STREQUAL "aarch64" )
>set(goarch "arm64")
> @@ -23,6 +26,10 @@ set(allgoos "aix" "android" "darwin" "dragonfly"
> "freebsd" "irix" "linux" "netbs
>  # Set library suffix based on target triple
>  if( ${llarch} STREQUAL "x86_64" )
>set(library_suffix "64")
> +elseif( ${llarch} STREQUAL "i686" )
> +# Driver::installedLibDir honors ./lib only, on Ubuntu 16
> +# But we can stick for ./lib32 (along with those in AddGollvm.cmake)
> +  set(library_suffix "32")
>  elseif( ${llarch} STREQUAL "aarch64" )
>  # Driver::installedLibDir honors ./lib64 only
>  # Future change needed (along with those in AddGollvm.cmake)
> diff --git a/cmake/modules/LibbacktraceUtils.cmake
> b/cmake/modules/LibbacktraceUtils.cmake
> index dc54f18..42287a9 100644
> --- a/cmake/modules/LibbacktraceUtils.cmake
> +++ b/cmake/modules/LibbacktraceUtils.cmake
> @@ -8,6 

Re: [go-nuts] gollvm: capture-fcn-attributes.go generates the header file with improperly chosen CPU model (i686; yonah)

['Than McIntosh' via golang-nuts]

Right, that would be expected.   The easiest thing to do is make sure that
you're running cmake in your build area with

   -DLLVM_TARGETS_TO_BUILD="all"

then you can build "llc" and "clang" , then update your path so that the
freshly built llc/clang are picked up first. Once you have that set up, it
should take care of the problem running "llc" from capture-fcn-attributes.

Than


On Wed, Jan 6, 2021 at 3:14 PM Ivan Serdyuk 
wrote:

> I think a caught an error:
>
> $ ./capture-fcn-attributes
>> llc run failed: llc: error: : error: unable to get target for
>> 'aarch64-unknown-linux-gnu', see --version and --triple.
>>
>> capture-fcn-attributes: err = exit status 1
>>
>
> . Hence that I didn't compile Aarch64 back-end, for LLVM:
>
> $ llc --version
>> LLVM (http://llvm.org/):
>>   LLVM version 12.0.0git
>>   Optimized build.
>>   Default target: i686-pc-linux-gnu
>>   Host CPU: yonah
>>
>>   Registered Targets:
>> x86- 32-bit X86: Pentium-Pro and above
>> x86-64 - 64-bit X86: EM64T and AMD64
>>
> . So this would not run out-of-the-box.
>
>
>
> On Wed, Jan 6, 2021 at 8:21 PM Than McIntosh  wrote:
>
>> Thanks. The error you're seeing
>>
>>   "unable to determine target CPU features for target i686-pc-linux-gnu"
>>
>> looks as though it's because i686-pc-linux-gnu isn't listed as a target in
>> driver/ArchCpusAttrs.h.
>>
>> From the root of your repo, try
>>
>>   $ cd tools
>>   $ go build capture-fcn-attributes.go
>>   $ ./capture-fcn-attributes -o ../driver/ArchCpusAttrs.h
>>
>> and then give the gollvm build another try.
>>
>> Thanks, Than
>>
>> On Wed, Jan 6, 2021 at 12:53 PM Ivan Serdyuk <
>> local.tourist.k...@gmail.com> wrote:
>>
>>> Here you go:
>>>
>>> ~/Desktop/workarea/llvm-project/llvm/tools/gollvm$ git diff
>>> diff --git a/cmake/modules/AutoGenGo.cmake
>>> b/cmake/modules/AutoGenGo.cmake
>>> index 3e3ab83..097a2ad 100644
>>> --- a/cmake/modules/AutoGenGo.cmake
>>> +++ b/cmake/modules/AutoGenGo.cmake
>>> @@ -51,6 +51,17 @@ function(mkversion goos goarch outfile bindir srcroot
>>> scriptroot)
>>>  set(pcquantum "1")
>>>  set(int64align "8")
>>>  set(minframesize 0)
>>> +  elseif( ${goarch} STREQUAL "386")
>>> +# Simply picking up one typical setting
>>> +# Align with current sets in gofrontend/libgo/goarch.sh
>>> +set(archfamily "I386")
>>> +set(bigendian "false")
>>> +set(cachelinesize "64")
>>> +set(physpagesize "4096")
>>> +set(pcquantum "1")
>>> +set(int64align "4")
>>> +set(minframesize 4)
>>> +set(ptrsize 4)
>>>elseif( ${goarch} STREQUAL "arm64")
>>>  # Simply picking up one typical setting
>>>  # Align with current sets in gofrontend/libgo/goarch.sh
>>> diff --git a/cmake/modules/GoVars.cmake b/cmake/modules/GoVars.cmake
>>> index ec6f6b2..0cea38a 100644
>>> --- a/cmake/modules/GoVars.cmake
>>> +++ b/cmake/modules/GoVars.cmake
>>> @@ -8,6 +8,9 @@ list(GET lht_components 2 goos)
>>>  # LLVM's "x86_64" is the same as Go's "amd64".
>>>  if( ${llarch} STREQUAL "x86_64" )
>>>set(goarch "amd64")
>>> +# For i386/i686
>>> +elseif( ${llarch} STREQUAL "i686" )
>>> +  set(goarch "386")
>>>  # LLVM's "aarch64" is the same as Go's "arm64".
>>>  elseif( ${llarch} STREQUAL "aarch64" )
>>>set(goarch "arm64")
>>> @@ -23,6 +26,10 @@ set(allgoos "aix" "android" "darwin" "dragonfly"
>>> "freebsd" "irix" "linux" "netbs
>>>  # Set library suffix based on target triple
>>>  if( ${llarch} STREQUAL "x86_64" )
>>>set(library_suffix "64")
>>> +elseif( ${llarch} STREQUAL "i686" )
>>> +# Driver::installedLibDir honors ./lib only, on Ubuntu 16
>>> +# But we can stick for ./lib32 (along with those in AddGollvm.cmake)
>>> +  set(library_suffix "32")
>>>  elseif( ${llarch} STREQUAL "aarch64" )
>>>  # Driver::installedLibDir honors ./lib64 only
>>>  # Future change needed (along with those in AddGollvm.cmake)
>>> diff --git a/cmake/modules/LibbacktraceUtils.cmake
>>> b/cmake/modules/LibbacktraceUtils.cmake
>>> index dc54f18..42287a9 100644
>>> --- a/cmake/modules/LibbacktraceUtils.cmake
>>> +++ b/cmake/modules/LibbacktraceUtils.cmake
>>> @@ -8,6 +8,9 @@ function(setup_libbacktrace)
>>>if( ${goarch} STREQUAL "amd64")
>>>  set(BACKTRACE_ELF_SIZE 64)
>>>  set(HAVE_GETIPINFO 1)
>>> +  elseif( ${goarch} STREQUAL "386")
>>> +set(BACKTRACE_ELF_SIZE 32)
>>> +set(HAVE_GETIPINFO 1)
>>>elseif( ${goarch} STREQUAL "arm64")
>>>  set(BACKTRACE_ELF_SIZE 64)
>>>  set(HAVE_GETIPINFO 1)
>>> diff --git a/cmake/modules/LibffiUtils.cmake
>>> b/cmake/modules/LibffiUtils.cmake
>>> index b3fa697..fb34c36 100644
>>> --- a/cmake/modules/LibffiUtils.cmake
>>> --- a/cmake/modules/LibffiUtils.cmake
>>> +++ b/cmake/modules/LibffiUtils.cmake
>>> @@ -9,6 +9,8 @@ function(setup_libffi libffi_srcroot)
>>>  set(arch_dir "aarch64")
>>>elseif(${llarch} STREQUAL "x86_64")
>>>  set(arch_dir "x86")
>>> +  elseif(${llarch} STREQUAL "i686")
>>> +set(arch_dir "x86")
>>>else()
>>>  message(SEND_ERROR "Arch ${llarch} not yet 

Re: [go-nuts] gollvm: capture-fcn-attributes.go generates the header file with improperly chosen CPU model (i686; yonah)

['Than McIntosh' via golang-nuts]

Thanks. The error you're seeing

  "unable to determine target CPU features for target i686-pc-linux-gnu"

looks as though it's because i686-pc-linux-gnu isn't listed as a target in
driver/ArchCpusAttrs.h.

>From the root of your repo, try

  $ cd tools
  $ go build capture-fcn-attributes.go
  $ ./capture-fcn-attributes -o ../driver/ArchCpusAttrs.h

and then give the gollvm build another try.

Thanks, Than

On Wed, Jan 6, 2021 at 12:53 PM Ivan Serdyuk 
wrote:

> Here you go:
>
> ~/Desktop/workarea/llvm-project/llvm/tools/gollvm$ git diff
> diff --git a/cmake/modules/AutoGenGo.cmake b/cmake/modules/AutoGenGo.cmake
> index 3e3ab83..097a2ad 100644
> --- a/cmake/modules/AutoGenGo.cmake
> +++ b/cmake/modules/AutoGenGo.cmake
> @@ -51,6 +51,17 @@ function(mkversion goos goarch outfile bindir srcroot
> scriptroot)
>  set(pcquantum "1")
>  set(int64align "8")
>  set(minframesize 0)
> +  elseif( ${goarch} STREQUAL "386")
> +# Simply picking up one typical setting
> +# Align with current sets in gofrontend/libgo/goarch.sh
> +set(archfamily "I386")
> +set(bigendian "false")
> +set(cachelinesize "64")
> +set(physpagesize "4096")
> +set(pcquantum "1")
> +set(int64align "4")
> +set(minframesize 4)
> +set(ptrsize 4)
>elseif( ${goarch} STREQUAL "arm64")
>  # Simply picking up one typical setting
>  # Align with current sets in gofrontend/libgo/goarch.sh
> diff --git a/cmake/modules/GoVars.cmake b/cmake/modules/GoVars.cmake
> index ec6f6b2..0cea38a 100644
> --- a/cmake/modules/GoVars.cmake
> +++ b/cmake/modules/GoVars.cmake
> @@ -8,6 +8,9 @@ list(GET lht_components 2 goos)
>  # LLVM's "x86_64" is the same as Go's "amd64".
>  if( ${llarch} STREQUAL "x86_64" )
>set(goarch "amd64")
> +# For i386/i686
> +elseif( ${llarch} STREQUAL "i686" )
> +  set(goarch "386")
>  # LLVM's "aarch64" is the same as Go's "arm64".
>  elseif( ${llarch} STREQUAL "aarch64" )
>set(goarch "arm64")
> @@ -23,6 +26,10 @@ set(allgoos "aix" "android" "darwin" "dragonfly"
> "freebsd" "irix" "linux" "netbs
>  # Set library suffix based on target triple
>  if( ${llarch} STREQUAL "x86_64" )
>set(library_suffix "64")
> +elseif( ${llarch} STREQUAL "i686" )
> +# Driver::installedLibDir honors ./lib only, on Ubuntu 16
> +# But we can stick for ./lib32 (along with those in AddGollvm.cmake)
> +  set(library_suffix "32")
>  elseif( ${llarch} STREQUAL "aarch64" )
>  # Driver::installedLibDir honors ./lib64 only
>  # Future change needed (along with those in AddGollvm.cmake)
> diff --git a/cmake/modules/LibbacktraceUtils.cmake
> b/cmake/modules/LibbacktraceUtils.cmake
> index dc54f18..42287a9 100644
> --- a/cmake/modules/LibbacktraceUtils.cmake
> +++ b/cmake/modules/LibbacktraceUtils.cmake
> @@ -8,6 +8,9 @@ function(setup_libbacktrace)
>if( ${goarch} STREQUAL "amd64")
>  set(BACKTRACE_ELF_SIZE 64)
>  set(HAVE_GETIPINFO 1)
> +  elseif( ${goarch} STREQUAL "386")
> +set(BACKTRACE_ELF_SIZE 32)
> +set(HAVE_GETIPINFO 1)
>elseif( ${goarch} STREQUAL "arm64")
>  set(BACKTRACE_ELF_SIZE 64)
>  set(HAVE_GETIPINFO 1)
> diff --git a/cmake/modules/LibffiUtils.cmake
> b/cmake/modules/LibffiUtils.cmake
> index b3fa697..fb34c36 100644
> --- a/cmake/modules/LibffiUtils.cmake
> --- a/cmake/modules/LibffiUtils.cmake
> +++ b/cmake/modules/LibffiUtils.cmake
> @@ -9,6 +9,8 @@ function(setup_libffi libffi_srcroot)
>  set(arch_dir "aarch64")
>elseif(${llarch} STREQUAL "x86_64")
>  set(arch_dir "x86")
> +  elseif(${llarch} STREQUAL "i686")
> +set(arch_dir "x86")
>else()
>  message(SEND_ERROR "Arch ${llarch} not yet supported")
>endif()
> diff --git a/driver/Driver.cpp b/driver/Driver.cpp
> index 8debbab..aa83fb1 100644
> --- a/driver/Driver.cpp
> +++ b/driver/Driver.cpp
> @@ -76,7 +76,7 @@ std::string Driver::installedLibDir()
>llvm::sys::path::append(ldir, "../lib64");
>break;
>  default:
> -  llvm::sys::path::append(ldir, "../lib64");
> +  llvm::sys::path::append(ldir, "../lib");
>break;
>}
> :
> --- a/cmake/modules/LibffiUtils.cmake
> +++ b/cmake/modules/LibffiUtils.cmake
> @@ -9,6 +9,8 @@ function(setup_libffi libffi_srcroot)
>  set(arch_dir "aarch64")
>elseif(${llarch} STREQUAL "x86_64")
>  set(arch_dir "x86")
> +  elseif(${llarch} STREQUAL "i686")
> +set(arch_dir "x86")
>else()
>  message(SEND_ERROR "Arch ${llarch} not yet supported")
>endif()
> diff --git a/driver/Driver.cpp b/driver/Driver.cpp
> index 8debbab..aa83fb1 100644
> --- a/driver/Driver.cpp
> +++ b/driver/Driver.cpp
> @@ -76,7 +76,7 @@ std::string Driver::installedLibDir()
>llvm::sys::path::append(ldir, "../lib64");
>break;
>  default:
> -  llvm::sys::path::append(ldir, "../lib64");
> +  llvm::sys::path::append(ldir, "../lib");
>break;
>}
>return std::string(ldir.str());
>
> and
>
> $ git log -1
> commit 850255c5cd7f9df79a148d537fd395089b7caf29 (HEAD -> master,
> origin/master, 

Re: [go-nuts] gollvm: capture-fcn-attributes.go generates the header file with improperly chosen CPU model (i686; yonah)

['Than McIntosh' via golang-nuts]

Diff is fine. No need for the entire folder.
Than


On Wed, Jan 6, 2021 at 10:18 AM Ivan Serdyuk 
wrote:

> Than,
> I could perform "git diff" and provide the generated file.
> I could also compress & share the build folder.
> What else would be required?
>
> Ivan
>
> On Wednesday, January 6, 2021 at 5:07:06 PM UTC+2 th...@google.com wrote:
>
>>
>> It would be helpful if you could put up a CL that includes all of the
>> changes you're testing -- at this point do you have any modifications to
>> driver/ArchCpusAttrs.h ?
>>
>> Thanks
>>
>>
>>
>> On Wed, Jan 6, 2021 at 10:00 AM Ivan Serdyuk 
>> wrote:
>>
>>> Ping
>>>
>>> On Friday, January 1, 2021 at 5:45:02 AM UTC+2 Ivan Serdyuk wrote:
>>>
 Happy New Year, Than.

 So I have rebuilt llvm-goc, after applying
 https://go-review.googlesource.com/c/gollvm/+/270219.
 Here
 
 is my compressed build folder.

 I am using
 $ clang --version
 clang version 12.0.0
 Target: i686-pc-linux-gnu
 Thread model: posix
 on
 $ uname -a
 Linux oceanfish81-A8He 4.15.0-129-generic #132-Ubuntu SMP Thu Dec 10
 14:07:35 UTC 2020 i686 i686 i686 GNU/Linux

 You can obtain a pre-compiler "MinSizeRel" build of LLVM (including
 Clang) here
 
 .

 I tried to build an avarage libgo package - and here is what I got:

 $ ninja libgo_golang.org_x_crypto_chacha20
 [1/120] Building Go package 'unicode' (non-PIC)
 FAILED: tools/gollvm/libgo/unicode.o
 cd /home/oceanfish81/Desktop/workarea/release/tools/gollvm/libgo &&
 /usr/local/bin/cmake -E make_directory ./. &&
 /home/oceanfish81/Desktop/workarea/release/./bin/llvm-goc -c -o
 /home/oceanfish81/Desktop/workarea/release/tools/gollvm/libgo/./unicode.o
 -fgo-pkgpath=unicode -I .
 /home/oceanfish81/Desktop/workarea/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/unicode/casetables.go
 /home/oceanfish81/Desktop/workarea/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/unicode/digit.go
 /home/oceanfish81/Desktop/workarea/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/unicode/graphic.go
 /home/oceanfish81/Desktop/workarea/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/unicode/letter.go
 /home/oceanfish81/Desktop/workarea/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/unicode/tables.go
 currently Gollvm is not supported on architecture i686
 /home/oceanfish81/Desktop/workarea/release/./bin/llvm-goc: *unable to
 determine target CPU features for target i686-pc-linux-gnu*
 [2/120] Building Go package 'internal/unsafeheader' (PIC)
 FAILED: tools/gollvm/libgo/internal/.pic/unsafeheader.o
 cd /home/oceanfish81/Desktop/workarea/release/tools/gollvm/libgo &&
 /usr/local/bin/cmake -E make_directory ./internal/.pic &&
 /home/oceanfish81/Desktop/workarea/release/./bin/llvm-goc -c -o
 /home/oceanfish81/Desktop/workarea/release/tools/gollvm/libgo/internal/.pic/unsafeheader.o
 -fPIC -fgo-pkgpath=internal/unsafeheader -I .
 /home/oceanfish81/Desktop/workarea/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/internal/unsafeheader/unsafeheader.go
 currently Gollvm is not supported on architecture i686
 /home/oceanfish81/Desktop/workarea/release/./bin/llvm-goc: *unable to
 determine target CPU features for target i686-pc-linux-gnu*
 ninja: build stopped: subcommand failed.

 Ivan
 On Tuesday, December 8, 2020 at 3:30:05 PM UTC+2 th...@google.com
 wrote:

> Hello,
>
> Thanks for the note.
>
> I am still not completely sure what the problem is.
>
>
> You wrote:
>
>  | I found
>  |
>  | // triple: i686-pc-linux-gnu
>  | static const CpuAttrs attrs1[] = {
>  | // first entry is default cpu
>  | { "i686", "+cx8,+x87"},
>  |
>  | and (inside the hashmap)
>  |
>  | { "yonah", "+cx8,+fxsr,+mmx,+sse,+sse2,+sse3,+x87"},
>  | , which is not what I have supported (for Intel Celeron M440).
>
> What makes you say that this is not what you have supported? Are you
> saying that the cpu clang calls "yonah" doesn't actually have one of
> these
> features (ex: sse3)?
>
>
>  | Clang reports "unsupported CPU features" on any non-provided one.
>  | So that is one big problem.
>
> Not sure what you mean here. Can you please post the complete clang
> invocation and error message you are getting?
>
>
>
>  | const TripleCpus triples[] = {
>  | { "x86_64-unknown-linux-gnu", [0] },
>  | { "i686-pc-linux-gnu", [0] },
>  | { "aarch64-unknown-linux-gnu", [0] },
>  | { "", nullptr } // sentinel
>  | };
>  | is not targeting to yonah, while llc is targeting it.
>  | It is always some "default" CPU model and, in fact, your 

Re: [go-nuts] gollvm: capture-fcn-attributes.go generates the header file with improperly chosen CPU model (i686; yonah)

['Than McIntosh' via golang-nuts]

It would be helpful if you could put up a CL that includes all of the
changes you're testing -- at this point do you have any modifications to
driver/ArchCpusAttrs.h ?

Thanks



On Wed, Jan 6, 2021 at 10:00 AM Ivan Serdyuk 
wrote:

> Ping
>
> On Friday, January 1, 2021 at 5:45:02 AM UTC+2 Ivan Serdyuk wrote:
>
>> Happy New Year, Than.
>>
>> So I have rebuilt llvm-goc, after applying
>> https://go-review.googlesource.com/c/gollvm/+/270219.
>> Here
>> 
>> is my compressed build folder.
>>
>> I am using
>> $ clang --version
>> clang version 12.0.0
>> Target: i686-pc-linux-gnu
>> Thread model: posix
>> on
>> $ uname -a
>> Linux oceanfish81-A8He 4.15.0-129-generic #132-Ubuntu SMP Thu Dec 10
>> 14:07:35 UTC 2020 i686 i686 i686 GNU/Linux
>>
>> You can obtain a pre-compiler "MinSizeRel" build of LLVM (including
>> Clang) here
>> 
>> .
>>
>> I tried to build an avarage libgo package - and here is what I got:
>>
>> $ ninja libgo_golang.org_x_crypto_chacha20
>> [1/120] Building Go package 'unicode' (non-PIC)
>> FAILED: tools/gollvm/libgo/unicode.o
>> cd /home/oceanfish81/Desktop/workarea/release/tools/gollvm/libgo &&
>> /usr/local/bin/cmake -E make_directory ./. &&
>> /home/oceanfish81/Desktop/workarea/release/./bin/llvm-goc -c -o
>> /home/oceanfish81/Desktop/workarea/release/tools/gollvm/libgo/./unicode.o
>> -fgo-pkgpath=unicode -I .
>> /home/oceanfish81/Desktop/workarea/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/unicode/casetables.go
>> /home/oceanfish81/Desktop/workarea/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/unicode/digit.go
>> /home/oceanfish81/Desktop/workarea/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/unicode/graphic.go
>> /home/oceanfish81/Desktop/workarea/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/unicode/letter.go
>> /home/oceanfish81/Desktop/workarea/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/unicode/tables.go
>> currently Gollvm is not supported on architecture i686
>> /home/oceanfish81/Desktop/workarea/release/./bin/llvm-goc: *unable to
>> determine target CPU features for target i686-pc-linux-gnu*
>> [2/120] Building Go package 'internal/unsafeheader' (PIC)
>> FAILED: tools/gollvm/libgo/internal/.pic/unsafeheader.o
>> cd /home/oceanfish81/Desktop/workarea/release/tools/gollvm/libgo &&
>> /usr/local/bin/cmake -E make_directory ./internal/.pic &&
>> /home/oceanfish81/Desktop/workarea/release/./bin/llvm-goc -c -o
>> /home/oceanfish81/Desktop/workarea/release/tools/gollvm/libgo/internal/.pic/unsafeheader.o
>> -fPIC -fgo-pkgpath=internal/unsafeheader -I .
>> /home/oceanfish81/Desktop/workarea/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/internal/unsafeheader/unsafeheader.go
>> currently Gollvm is not supported on architecture i686
>> /home/oceanfish81/Desktop/workarea/release/./bin/llvm-goc: *unable to
>> determine target CPU features for target i686-pc-linux-gnu*
>> ninja: build stopped: subcommand failed.
>>
>> Ivan
>> On Tuesday, December 8, 2020 at 3:30:05 PM UTC+2 th...@google.com wrote:
>>
>>> Hello,
>>>
>>> Thanks for the note.
>>>
>>> I am still not completely sure what the problem is.
>>>
>>>
>>> You wrote:
>>>
>>>  | I found
>>>  |
>>>  | // triple: i686-pc-linux-gnu
>>>  | static const CpuAttrs attrs1[] = {
>>>  | // first entry is default cpu
>>>  | { "i686", "+cx8,+x87"},
>>>  |
>>>  | and (inside the hashmap)
>>>  |
>>>  | { "yonah", "+cx8,+fxsr,+mmx,+sse,+sse2,+sse3,+x87"},
>>>  | , which is not what I have supported (for Intel Celeron M440).
>>>
>>> What makes you say that this is not what you have supported? Are you
>>> saying that the cpu clang calls "yonah" doesn't actually have one of
>>> these
>>> features (ex: sse3)?
>>>
>>>
>>>  | Clang reports "unsupported CPU features" on any non-provided one.
>>>  | So that is one big problem.
>>>
>>> Not sure what you mean here. Can you please post the complete clang
>>> invocation and error message you are getting?
>>>
>>>
>>>
>>>  | const TripleCpus triples[] = {
>>>  | { "x86_64-unknown-linux-gnu", [0] },
>>>  | { "i686-pc-linux-gnu", [0] },
>>>  | { "aarch64-unknown-linux-gnu", [0] },
>>>  | { "", nullptr } // sentinel
>>>  | };
>>>  | is not targeting to yonah, while llc is targeting it.
>>>  | It is always some "default" CPU model and, in fact, your code never
>>> provided extraction of the CPU model (from llc).
>>>  |
>>>
>>> When llc emits the line
>>>
>>>   Host CPU: yonah
>>>
>>> this does not mean that clang/llc will automatically target 'yonah' when
>>> compiling, it just means that the program has detected the host CPU.
>>>
>>> Generally speaking if you want clang to produce code targeted
>>> specifically to the host CPU, you have to use -march=native or
>>> -mtune-native.
>>>
>>> Thanks, Than
>>>
>>> On Fri, Dec 4, 2020 at 8:08 PM Ivan Serdyuk 
>>> wrote:
>>>
 Hello.

 This issue is related to
 

Re: [go-nuts] gollvm: capture-fcn-attributes.go generates the header file with improperly chosen CPU model (i686; yonah)

['Than McIntosh' via golang-nuts]

Hello,

Thanks for the note.

I am still not completely sure what the problem is.

You wrote:

 | I found
 |
 | // triple: i686-pc-linux-gnu
 | static const CpuAttrs attrs1[] = {
 | // first entry is default cpu
 | { "i686", "+cx8,+x87"},
 |
 | and (inside the hashmap)
 |
 | { "yonah", "+cx8,+fxsr,+mmx,+sse,+sse2,+sse3,+x87"},
 | , which is not what I have supported (for Intel Celeron M440).

What makes you say that this is not what you have supported? Are you
saying that the cpu clang calls "yonah" doesn't actually have one of these
features (ex: sse3)?

 | Clang reports "unsupported CPU features" on any non-provided one.
 | So that is one big problem.

Not sure what you mean here. Can you please post the complete clang
invocation and error message you are getting?


 | const TripleCpus triples[] = {
 | { "x86_64-unknown-linux-gnu", [0] },
 | { "i686-pc-linux-gnu", [0] },
 | { "aarch64-unknown-linux-gnu", [0] },
 | { "", nullptr } // sentinel
 | };
 | is not targeting to yonah, while llc is targeting it.
 | It is always some "default" CPU model and, in fact, your code never
provided extraction of the CPU model (from llc).
 |

When llc emits the line

  Host CPU: yonah

this does not mean that clang/llc will automatically target 'yonah' when
compiling, it just means that the program has detected the host CPU.

Generally speaking if you want clang to produce code targeted specifically
to the host CPU, you have to use -march=native or -mtune-native.

Thanks, Than

On Fri, Dec 4, 2020 at 8:08 PM Ivan Serdyuk 
wrote:

> Hello.
>
> This issue is related to
> https://go-review.googlesource.com/c/gollvm/+/274574
> .
>
> I think I have some misunderstanding on how you used to deal with CPU
> models, for LLVM.
>
> First things first - I had success with using
>
> #include "llvm/ADT/StringRef.h"
> #include "llvm/ADT/StringMap.h"
> #include "llvm/MC/SubtargetFeature.h"
> #include "llvm/Support/Host.h"
>
> using namespace llvm;
> SubtargetFeatures Features1;
>
> int main (int argc, char **argv)
> {
> sys::getHostCPUName();
> StringMap HostFeatures;
> if (sys::getHostCPUFeatures(HostFeatures))
> for (auto  : HostFeatures)
> Features1.AddFeature(F.first(), F.second);
>
> printf("test %s", Features1.getString().c_str());
> printf("\nsomething else\n");
> return 0;
> }
> . It gives me such a set of CPU features:
>
>
> +sse2,-tsxldtrk,-cx16,-sahf,-tbm,-avx512ifma,-sha,-gfni,-fma4,-vpclmulqdq,-prfchw,-bmi2,-cldemote,-fsgsbase,-ptwrite,-amx-tile,-avx512bf16,-popcnt,-aes,-avx512bitalg,-movdiri,-xsaves,-avx512er,-xsavec,-avx512vnni,-amx-bf16,-avx512vpopcntdq,-pconfig,-clwb,-avx512f,-clzero,-pku,+mmx,-lwp,-rdpid,-xop,-rdseed,-waitpkg,-movdir64b,-sse4a,-avx512bw,-clflushopt,-xsave,-avx512vbmi2,-64bit,-avx512vl,-serialize,-invpcid,-avx512cd,-avx,-vaes,+cx8,-fma,-rtm,-bmi,-enqcmd,-rdrnd,-mwaitx,-sse4.1,-sse4.2,-avx2,+fxsr,-wbnoinvd,+sse,-lzcnt,-pclmul,-prefetchwt1,-f16c,-ssse3,-sgx,-shstk,+cmov,-avx512vbmi,-amx-int8,-movbe,-avx512vp2intersect,-xsaveopt,-avx512dq,-adx,-avx512pf,+sse3
>
> $ llc --version
> provides
> Default target: i686-pc-linux-gnu
> Host CPU: yonah
> .
>
> I tried to update the capture-fcn-attributes.go file, like this:
>
> var supportedTriples []string = []string{
> "x86_64-unknown-linux-gnu",
> "i686-pc-linux-gnu",
> "aarch64-unknown-linux-gnu",
> }
> .
>
> When I tried the generator
>
> capture-fcn-attributes -o /tmp/cpu_feature_list
> it generated me a broad list.
> The header contained
>
> Ubuntu clang version 11.0.0-++20200721055954+cebd637c886-1exp1
> 20200721161335.13
> .
> I found
>
> // triple: i686-pc-linux-gnu
> static const CpuAttrs attrs1[] = {
> // first entry is default cpu
> { "i686", "+cx8,+x87"},
>
> and (inside the hashmap)
>
> { "yonah", "+cx8,+fxsr,+mmx,+sse,+sse2,+sse3,+x87"},
> , which is not what I have supported (for Intel Celeron M440).
> Clang reports "unsupported CPU features" on any non-provided one.
> So that is one big problem.
> Next problem is that
>
> const TripleCpus triples[] = {
> { "x86_64-unknown-linux-gnu", [0] },
> { "i686-pc-linux-gnu", [0] },
> { "aarch64-unknown-linux-gnu", [0] },
> { "", nullptr } // sentinel
> };
> is not targeting to yonah, while llc is targeting it.
> It is always some "default" CPU model and, in fact, your code never
> provided extraction of the CPU model (from llc).
>
> To make my observation complete - I am providing what is generated via
>
> capture-fcn-attributes -cpu yonah
> :
>
> // triple: x86_64-unknown-linux-gnu
> static const CpuAttrs attrs0[] = {
> // first entry is default cpu
> { "x86-64", "+cx8,+fxsr,+mmx,+sse,+sse2,+x87"},
> { "", "" } // sentinel
> };
>
> // triple: i686-pc-linux-gnu
> static const CpuAttrs attrs1[] = {
> // first entry is default cpu
> { "i686", "+cx8,+x87"},
> { "yonah", "+cx8,+fxsr,+mmx,+sse,+sse2,+sse3,+x87"},
> { "", "" } // sentinel
> };
>
> // triple: aarch64-unknown-linux-gnu
> static const CpuAttrs attrs2[] = {
> // first entry is default cpu
> { "generic", "+neon"},
> { "", "" } // sentinel
> };
>
> 

Re: [go-nuts] Does it support using external package in gollvm?

['Than McIntosh' via golang-nuts]

Can you please post the exact commands you're using?

The recipe in https://go.googlesource.com/gollvm#seetheir is meant to give
you an idea as to how to do this, but without seeing exactly what you typed
it's hard to tell what the problem s.

Thanks.

On Thu, Nov 19, 2020 at 8:57 AM jw jiang  wrote:

> i've read some papers said that he changed the go source file to llvm ir
> using llgo.
> but i found that llgo is not maintained .
>
> So i search and find gollvm  in
> https://go.googlesource.com/gollvm#seetheir.
>
> i follow its instruction steps and build the gollvm and llvm-goc
> successfully.
>
> But something confuse me that is i can not import external package while
> using llvm-goc to dump llvm ir.
>
> For example, i've tried dump the code below to llvm-ir,
>
> ===
> *package main*
>
> *import (*
> *"fmt"*
> *"test/testg"*
> *)*
>
> *func add(x, y int) int {*
> *return x + y*
> *}*
>
>
> *func main() {*
> *var c = testg.Color{}*
> *a := 5000*
> *//b := 4*
> *fmt.Println(add(a, c.C))*
> *}*
> ===
> But llvm-goc returns errors:
>
> ===
> *./main.go:5:15: error: import file 'test/testg' not found*
> *./main.go:14:24: error: expected ';' or '}' or newline*
> *./main.go:15:5: error: expected declaration*
> *./main.go:17:5: error: expected declaration*
> *./main.go:18:1: error: expected declaration*
> *./main.go:14:13: error: reference to undefined name 'testg'*
> ===
>
> I wonder whether the llvm-goc can use external packages? Or is there
> anyway to dump llvm-ir from go source file ?
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/5ae30fb1-1461-4b40-bfb9-6845a40dd31an%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BUr55E5SnvsijKBWpwM%3Do2yVCwDbfeR_8yg3AnTQZGc8Q_QSw%40mail.gmail.com.

Re: [go-nuts] gollvm: Issues on Alpine linux. Tentative definition has type 'struct sigstack' that is never completed, in sysinfo.c

['Than McIntosh' via golang-nuts]

>
/home/oceanfish81/workarea/llvm-project/llvm/tools/gollvm/gofrontend/libgo/sysinfo.c:462:1:
error: tentative definition has type 'struct sigstack' that is never
completed
> SREF(sigstack);
> ^

I don't know why sysinfo.c has the line "SREF(sigstack)".  What
happens if you just remove it?

I agree, I would take it out and see what happens.

The SREF(...) constructs in sysinfo.c are there to generate explicit
references to types mentioned in the C code from system header files, so as
to insure that DWARF gets generated for them (in case the C++ compiler
being used is clang, which does not
support -fno-eliminate-unused-debug-types).  Looks like on Alpine (which is
musl-based) there is no such type.   Not clear whether it is
actually needed at this point, so it is worth trying without it.

Thanks, Than



On Sun, Nov 15, 2020 at 11:51 AM Ian Lance Taylor  wrote:

> On Sun, Nov 15, 2020 at 7:25 AM Ivan Serdyuk
>  wrote:
> >
> > I was trying to check what is required to build gollvm on Alpine linux
> (it has musl instead of glibc).
> >
> > Look like recently revealed set of minimal requirements allowed to build
> the configuration file (for Ninja).
> >
> > heading to check whether Ninja would compile.
> > I wasn't able to find a pre-compiled Clang 11, for Alpine - but Clang 10
> was available, which was pre-compiled against musl (C++ standard library
> has to rely on musl, instead of glibc - as I suppose).
> >
> > Maybe I would recompile Clang 11, for Alpine distro - but not today.
> >
> > Must admit that CMake worked much faster, compared to Ubuntu.
> >
> > Comments would be much appreciated.
> >
> > So, I am stuck:
> >
> > [1/1084] Building sysinfo.o
> > FAILED: tools/gollvm/libgo/sysinfo.o
> > cd /home/oceanfish81/workarea/build_release/tools/gollvm/libgo &&
> /usr/bin/clang -g3 -c -fno-eliminate-unused-debug-types
> /home/oceanfish81/workarea/llvm-project/llvm/tools/gollvm/gofrontend/libgo/sysinfo.c
> -o /home/oceanfish81/workarea/build_release/tools/gollvm/libgo/sysinfo.o
> -D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
> -I/home/oceanfish81/workarea/build_release/tools/gollvm/libgo
> -I/home/oceanfish81/workarea/build_release/tools/gollvm/libgo/runtime
> >
> /home/oceanfish81/workarea/llvm-project/llvm/tools/gollvm/gofrontend/libgo/sysinfo.c:462:1:
> error: tentative definition has type 'struct sigstack' that is never
> completed
> > SREF(sigstack);
> > ^
>
> I don't know why sysinfo.c has the line "SREF(sigstack)".  What
> happens if you just remove it?
>
> Ian
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAOyqgcX3XtC4mr_atXaj8%2BBeicqsbOKZmw8kzKU9DYXaXAP9mw%40mail.gmail.com
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BUr55FtzED%3Das9TaExL2%3D3oMxCn7oeFparj_DQOUCyGSKeyzQ%40mail.gmail.com.

Re: [go-nuts] New linker

['Than McIntosh' via golang-nuts]

To be clear, a fair amount of DWARF generation is already done in the
compiler (bulk of the line table, subprogram DIEs and inline DIEs, debug
ranges, etc).

As far as I know, there are no near term plans (at least within the
compiler+runtime team) to work on moving  other bits of DWARF generation to
the compiler from the linker, but I don't think there would be any
objection to someone else doing it.

Than

On Wed, Aug 19, 2020 at 11:21 AM Misha Gusarov  wrote:

> Hello Than,
>
> Are there plans to implement remaining pieces (I'm interested
> ing moving DWARF generation from linker to compiler) for 1.17, or is the
> project considered done for now?
>
> Best,
> Misha.
>
> On 18 Aug 2020, at 19:22, 'Than McIntosh' via golang-nuts wrote:
>
>
> To add to what Ian mentioned:
>
> Many of the measures outlined in https://golang.org/s/better-linker have
> been implemented at this point.  It was a multi-person effort, several
> members of the Go compiler/runtime team were involved (Jeremy, Cherry,
> Austin, and myself).
>
> The new indexed object file format and the improved deadcode
> implementation went into the tree in time to be included in Go 1.15.
>
> The additional changes in Go 1.16 include better streaming of data and
> relocations from object file to linker output, a rewrite of the pclntab
> code, support for content-addressable symbols, and more complete cleanup of
> the old legacy linker data structures (e.g. removal of sym.Symbol).
>
> Some things mentioned in the doc that didn't get implemented include
> moving to DWARF 5, and moving DWARF type generation from the linker to the
> compiler.
>
> HTH.
>
> Cheers, Than
>
> On Sun, Aug 16, 2020 at 12:46 AM Ian Lance Taylor  wrote:
>
>> On Sat, Aug 15, 2020 at 11:49 AM Amnon  wrote:
>> >
>> > What is the best place to read about the ongoing work on the new linker?
>> > With the Go 1.15 release, how far along are we with the plans?
>> > What has been achieved?
>> > And what is still to come?
>>
>> The work on the new linker is close to complete and has been merged
>> into tip for the future 1.16 release (although 1.16 won't be released
>> until next February).  The work is as described at
>> https://golang.org/s/better-linker.
>>
>> Ian
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXEK_OWZxKOUieHBdoH4R0eyddu_cMf_p_udWSKgZsHdA%40mail.gmail.com
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CA%2BUr55EHRz5O3HvdP6xwOZyrHWKJA-Oc%2B96nMOCnB%3DmzABTYqA%40mail.gmail.com
> <https://groups.google.com/d/msgid/golang-nuts/CA%2BUr55EHRz5O3HvdP6xwOZyrHWKJA-Oc%2B96nMOCnB%3DmzABTYqA%40mail.gmail.com?utm_medium=email_source=footer>
> .
>
>
> --
> Misha
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BUr55F9H3dk%2BV0asL8Mkjhx0ENWr%2BDBpoiW9ObhzTCaWNV3jw%40mail.gmail.com.

Re: [go-nuts] New linker

['Than McIntosh' via golang-nuts]

To add to what Ian mentioned:

Many of the measures outlined in https://golang.org/s/better-linker have
been implemented at this point.  It was a multi-person effort, several
members of the Go compiler/runtime team were involved (Jeremy, Cherry,
Austin, and myself).

The new indexed object file format and the improved deadcode implementation
went into the tree in time to be included in Go 1.15.

The additional changes in Go 1.16 include better streaming of data and
relocations from object file to linker output, a rewrite of the pclntab
code, support for content-addressable symbols, and more complete cleanup of
the old legacy linker data structures (e.g. removal of sym.Symbol).

Some things mentioned in the doc that didn't get implemented include moving
to DWARF 5, and moving DWARF type generation from the linker to the
compiler.

HTH.

Cheers, Than

On Sun, Aug 16, 2020 at 12:46 AM Ian Lance Taylor  wrote:

> On Sat, Aug 15, 2020 at 11:49 AM Amnon  wrote:
> >
> > What is the best place to read about the ongoing work on the new linker?
> > With the Go 1.15 release, how far along are we with the plans?
> > What has been achieved?
> > And what is still to come?
>
> The work on the new linker is close to complete and has been merged
> into tip for the future 1.16 release (although 1.16 won't be released
> until next February).  The work is as described at
> https://golang.org/s/better-linker.
>
> Ian
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXEK_OWZxKOUieHBdoH4R0eyddu_cMf_p_udWSKgZsHdA%40mail.gmail.com
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BUr55EHRz5O3HvdP6xwOZyrHWKJA-Oc%2B96nMOCnB%3DmzABTYqA%40mail.gmail.com.

Re: [go-nuts] Why gollvm not support race detector?

['Than McIntosh' via golang-nuts]

>>Could I simply add race.go to gofrontend then link the target programs by
the TSAN shared library to make the race detector enabled?

The race detector implementation also includes a compiler component (look
for flag_race in the cmd/compile source code), so that would have to be
ported to gccgo as well, since gccgo uses an entirely different compiler
implementation. There are probably other things as well that would have to
be pulled in.

Than

On Tue, Aug 11, 2020 at 5:02 AM Ting Yuan  wrote:

> Thanks for your reply,
>
> If I'm not confused, the implementation of Go race detector is written in
> go/src/runtime/race .go and its
> TSAN implementation (in C/C++) is dynamic linked to target programs by a
> shared library. Could I simply add race.go to gofrontend then link the
> target programs by the TSAN shared library to make the race detector
> enabled? I know integrating the race detector to gccgo/gollvm can't be done
> as easily as the aforementioned method, but what problems will I encounter
> when I do this.
>
> Thanks, Ting
>
> On Saturday, August 8, 2020 at 12:36:54 AM UTC+8, Ian Lance Taylor wrote:
>>
>> On Thu, Aug 6, 2020 at 11:33 PM Yuan Ting  wrote:
>> >
>> > I know from README that gollvm does not support race detector. Is there
>> any technical problem? Is it possible to use ThreadSanitizer in LLVM to
>> implement a workaround race detector in gollvm?
>>
>> ThreadSanitizer knows a great deal about the behavior of C library
>> functions.  In order to use it with GoLLVM, it would be necessary to
>> teach it about the behavior of Go library functions.  This is not
>> impossible--the same work was done for the Go race detector--but
>> somebody would have to do the work.
>>
>> Ian
>>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/c6d696b5-4918-4926-9068-ff3cd2ae1118o%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BUr55GM1qvs6yaNFHqzGXSLYudFGxhRQusuO2X9jxwfo9T5Kw%40mail.gmail.com.

Re: [go-nuts] Gollvm failed to build hugo

['Than McIntosh' via golang-nuts]

Hello,

>># github.com/gohugoio/hugo
>>/usr/bin/ld.gold: error: $WORK/b029/_pkg_.a(gccgo_c.o): failed to match
split-stack sequence at section 1 offset 0

This issue is https://github.com/golang/go/issues/38728, which should be
fixed at this point at tip.

Thanks, Than


On Mon, Jul 20, 2020 at 2:33 PM Ian Lance Taylor  wrote:

> [ + thanm, cherryyz ]
>
> On Mon, Jul 20, 2020 at 4:24 AM Yuan Ting  wrote:
> >
> > Hi, I try to build hugo with fresh gollvm but the linker complains that:
> >
> > # github.com/gohugoio/hugo
> > /usr/bin/ld.gold: error: $WORK/b029/_pkg_.a(gccgo_c.o): failed to match
> split-stack sequence at section 1 offset 0
> > /usr/bin/ld.gold: error: $WORK/b029/_pkg_.a(gccgo_c.o): failed to match
> split-stack sequence at section 1 offset a6
> >
> > To reproduce:
> >
> > git clone https://github.com/gohugoio/hugo.git
> > cd hugo && go build
> >
> > Platform: x86_64 ubuntu:20.04
> > Gollvm build flags:
> > cmake ../llvm -DCMAKE_BUILD_TYPE=Release -DLLVM_TARGETS_TO_BUILD=X86
> -DLLVM_ENABLE_ASSERTIONS=On -DLLVM_ENABLE_RTTI=On -DLLVM_USE_LINKER=gold -G
> Ninja
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "golang-nuts" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to golang-nuts+unsubscr...@googlegroups.com.
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/d722a1e8-d205-4c9e-8ae4-623c19dd2946o%40googlegroups.com
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BUr55Ef1WZJ9kQAiTJ3-u3dkAGOCeBbUi1akpDWUy5Lay%2BLkA%40mail.gmail.com.

Re: [go-nuts] Problems compiling gollvm macos

['Than McIntosh' via golang-nuts]

Hello,
Gollvm is not support for MacOS at the moment-- the runtime (shared with
gccgo) doesn't target MacOS.
Cheers, Than


On Fri, Jun 19, 2020 at 2:19 PM Guido Chari  wrote:

> Hi,
>
> I am having problems to compile gollvm.
> I am following the instructions in https://go.googlesource.com/gollvm/,
> and I am running a macos mojave.
> I can not complete the cmake. Below the beggining of the error log.
> Any pointers?
>
> ```
> Checking whether the ASM compiler is GNU using "--version" did not match
> "(GNU assembler)|(GCC)|(Free Software Foundation)":
> Apple LLVM version 10.0.1 (clang-1001.0.46.4)
> Target: x86_64-apple-darwin18.7.0
> Thread model: posix
> InstalledDir: /Library/Developer/CommandLineTools/usr/bin
> Checking whether the ASM compiler is Clang using "--version" did not match
> "(clang version)":
> Apple LLVM version 10.0.1 (clang-1001.0.46.4)
> Target: x86_64-apple-darwin18.7.0
> Thread model: posix
> InstalledDir: /Library/Developer/CommandLineTools/usr/bin
> Determining if the include file link.h exists failed with the following
> output:
> Change Dir: /Users/guidochari/Documents/Projects/Testing/Symbolic
> Execution/workarea/build-debug/CMakeFiles/CMakeTmp
>
> Run Build Command(s):/usr/local/bin/ninja cmTC_e14c9 && [1/2] Building C
> object CMakeFiles/cmTC_e14c9.dir/CheckIncludeFile.c.o
> FAILED: CMakeFiles/cmTC_e14c9.dir/CheckIncludeFile.c.o
> /Library/Developer/CommandLineTools/usr/bin/cc   -isysroot
> /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk -o
> CMakeFiles/cmTC_e14c9.dir/CheckIncludeFile.c.o   -c CheckIncludeFile.c
> CheckIncludeFile.c:1:10: fatal error: 'link.h' file not found
> #include 
>  ^~~~
> 1 error generated.
> ninja: build stopped: subcommand failed.
>
>
>
> Determining if the include file valgrind/valgrind.h exists failed with the
> following output:
> Change Dir: /Users/guidochari/Documents/Projects/Testing/Symbolic
> Execution/workarea/build-debug/CMakeFiles/CMakeTmp
>
> Run Build Command(s):/usr/local/bin/ninja cmTC_6dcf0 && [1/2] Building C
> object CMakeFiles/cmTC_6dcf0.dir/CheckIncludeFile.c.o
> FAILED: CMakeFiles/cmTC_6dcf0.dir/CheckIncludeFile.c.o
> /Library/Developer/CommandLineTools/usr/bin/cc   -isysroot
> /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk -o
> CMakeFiles/cmTC_6dcf0.dir/CheckIncludeFile.c.o   -c CheckIncludeFile.c
> CheckIncludeFile.c:1:10: fatal error: 'valgrind/valgrind.h' file not found
> #include 
>  ^
> 1 error generated.
> ninja: build stopped: subcommand failed.
> ```
>
> Cheers,
> Guido.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/bd6687ed-c864-44e6-81ef-37dbd16934d2o%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BUr55EVWYKN6Xy8C_JK_PhqReeSoYKbXAsAT7bv4NJxb6v%2B6Q%40mail.gmail.com.

Re: [go-nuts] Failed to build gollvm in a docker container

['Than McIntosh' via golang-nuts]

>> 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 will add the
right flags under the hood to work around it.

>>root@a78010e8da5d:~# go version
>>go: symbol lookup error:
/root/llvm-project/install-release/lib64/libgo.so.11git: undefined symbol:
__go_getcontext

This symbol is defined in an assembly source file in libgo. What's
happening is that by setting CMAKE_C_FLAGS="-fcf-protection=none" but not
also setting CMAKE_ASM_FLAGS="-fcf-protection=none" you've introduced a
discrepancy between the C and Assembly compiles in libgo. If you
set CMAKE_C_FLAGS, you should also set CMAKE_ASM_FLAGS.

Thanks, Than


On Wed, May 27, 2020 at 10:02 AM Yuan Ting  wrote:

> 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.11git: undefined symbol:
> __go_getcontext
>
> On Wednesday, May 27, 2020 at 12:01:06 AM UTC+8, Than McIntosh wrote:
>>
>>
>> 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
>> suggest deleting and recreating your build area or removing your
>> CMakeCache.txt file to insure that you have a rebuild from a clean start.
>>
>> Thanks, Than
>>
>>
>> On Tue, May 26, 2020 at 11:00 AM Yuan Ting  wrote:
>>
>>> 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: 00 00
>>>d: 72 11jb 20 
>>>f: 48 83 ec 08  sub$0x8,%rsp
>>>   13: e8 00 00 00 00callq  18 
>>> 14: R_X86_64_PLT32 __errno_location-0x4
>>>   18: 48 63 00  movslq (%rax),%rax
>>>   1b: 48 83 c4 08  add$0x8,%rsp
>>>   1f: c3retq
>>>   20: 41 ba 08 00 00 00mov$0x8,%r10d
>>>   26: 45 31 db  xor%r11d,%r11d
>>>   29: e8 00 00 00 00callq  2e 
>>> 2a: R_X86_64_PLT32 __morestack-0x4
>>>   2e: c3retq
>>>   2f: f3 0f 1e fa  endbr64
>>>   33: eb dajmpf 
>>>
>>> On Tuesday, May 26, 2020 at 10:44:03 PM UTC+8, Than McIntosh wrote:

 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 70 00cmp%fs:0x70,%rsp
7:   00 00
9:   72 11   jb 1c 
b:   48 83 ec 08 sub$0x8,%rsp
f:   e8 00 00 00 00  callq  14 
 10: R_X86_64_PLT32  __errno_location-0x4

 Thanks, Than

 ?

 On Tue, May 26, 2020 at 10:05 AM Yuan Ting  wrote:

> 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/runtime
> -Itools/gollvm/libgo/runtime
> -I/root/llvm-project/llvm/tools/gollvm/libgo/libbacktrace -fPIC
> -Werror=date-time -Wall -Wextra -Wno-unused-parameter -Wwrite-strings
> -Wno-missing-field-initializers -pedantic -Wno-long-long
> -Wimplicit-fallthrough -Wno-comment -fdiagnostics-color 
> -ffunction-sections
> -fdata-sections -O3-fPIC -g -Wno-zero-length-array -fsplit-stack
> -D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64   -UNDEBUG -MD 
> -MT
> tools/gollvm/libgo/CMakeFiles/libgo_c_piclib.dir/__/gofrontend/libgo/go/syscall/errno.c.o
> -MF
> tools/gollvm/libgo/CMakeFiles/libgo_c_piclib.dir/__/gofrontend/libgo/go/syscall/errno.c.o.d
> -o
> tools/gollvm/libgo/CMakeFiles/libgo_c_piclib.dir/__/gofrontend/libgo/go/syscall/errno.c.o
>  -c 
> /root/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/syscall/errno.c
>
> On Tuesday, May 26, 2020 at 8:41:18 PM UTC+8, Than McIntosh wrote:
>>
>> OK.
>>
>> 

Re: [go-nuts] Failed to build gollvm in a docker container

['Than McIntosh' via golang-nuts]

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
suggest deleting and recreating your build area or removing your
CMakeCache.txt file to insure that you have a rebuild from a clean start.

Thanks, Than


On Tue, May 26, 2020 at 11:00 AM Yuan Ting  wrote:

> 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: 00 00
>d: 72 11jb 20 
>f: 48 83 ec 08  sub$0x8,%rsp
>   13: e8 00 00 00 00callq  18 
> 14: R_X86_64_PLT32 __errno_location-0x4
>   18: 48 63 00  movslq (%rax),%rax
>   1b: 48 83 c4 08  add$0x8,%rsp
>   1f: c3retq
>   20: 41 ba 08 00 00 00mov$0x8,%r10d
>   26: 45 31 db  xor%r11d,%r11d
>   29: e8 00 00 00 00callq  2e 
> 2a: R_X86_64_PLT32 __morestack-0x4
>   2e: c3retq
>   2f: f3 0f 1e fa  endbr64
>   33: eb dajmpf 
>
> On Tuesday, May 26, 2020 at 10:44:03 PM UTC+8, Than McIntosh wrote:
>>
>> 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 70 00cmp%fs:0x70,%rsp
>>7:   00 00
>>9:   72 11   jb 1c 
>>b:   48 83 ec 08 sub$0x8,%rsp
>>f:   e8 00 00 00 00  callq  14 
>> 10: R_X86_64_PLT32  __errno_location-0x4
>>
>> Thanks, Than
>>
>> ?
>>
>> On Tue, May 26, 2020 at 10:05 AM Yuan Ting  wrote:
>>
>>> 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/runtime
>>> -Itools/gollvm/libgo/runtime
>>> -I/root/llvm-project/llvm/tools/gollvm/libgo/libbacktrace -fPIC
>>> -Werror=date-time -Wall -Wextra -Wno-unused-parameter -Wwrite-strings
>>> -Wno-missing-field-initializers -pedantic -Wno-long-long
>>> -Wimplicit-fallthrough -Wno-comment -fdiagnostics-color -ffunction-sections
>>> -fdata-sections -O3-fPIC -g -Wno-zero-length-array -fsplit-stack
>>> -D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64   -UNDEBUG -MD -MT
>>> tools/gollvm/libgo/CMakeFiles/libgo_c_piclib.dir/__/gofrontend/libgo/go/syscall/errno.c.o
>>> -MF
>>> tools/gollvm/libgo/CMakeFiles/libgo_c_piclib.dir/__/gofrontend/libgo/go/syscall/errno.c.o.d
>>> -o
>>> tools/gollvm/libgo/CMakeFiles/libgo_c_piclib.dir/__/gofrontend/libgo/go/syscall/errno.c.o
>>>  -c /root/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/syscall/errno.c
>>>
>>> On Tuesday, May 26, 2020 at 8:41:18 PM UTC+8, Than McIntosh wrote:

 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, May 26, 2020 at 7:21 AM Yuan Ting  wrote:

> 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/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, 2020 at 10:15 PM Yuan Ting  wrote:
>>
>>> 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 Ninja ../llvm
>>>
>>> and then build and install gollvm by
>>>
>>> ninja gollvm && ninja install-gollvm
>>>
>>> after a while, I encountered
>>>
>>> ...
>>>

Re: [go-nuts] Failed to build gollvm in a docker container

['Than McIntosh' via golang-nuts]

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 70 00cmp%fs:0x70,%rsp
   7:   00 00
   9:   72 11   jb 1c 
   b:   48 83 ec 08 sub$0x8,%rsp
   f:   e8 00 00 00 00  callq  14 
10: R_X86_64_PLT32  __errno_location-0x4

Thanks, Than

?

On Tue, May 26, 2020 at 10:05 AM Yuan Ting  wrote:

> 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/runtime
> -Itools/gollvm/libgo/runtime
> -I/root/llvm-project/llvm/tools/gollvm/libgo/libbacktrace -fPIC
> -Werror=date-time -Wall -Wextra -Wno-unused-parameter -Wwrite-strings
> -Wno-missing-field-initializers -pedantic -Wno-long-long
> -Wimplicit-fallthrough -Wno-comment -fdiagnostics-color -ffunction-sections
> -fdata-sections -O3-fPIC -g -Wno-zero-length-array -fsplit-stack
> -D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64   -UNDEBUG -MD -MT
> tools/gollvm/libgo/CMakeFiles/libgo_c_piclib.dir/__/gofrontend/libgo/go/syscall/errno.c.o
> -MF
> tools/gollvm/libgo/CMakeFiles/libgo_c_piclib.dir/__/gofrontend/libgo/go/syscall/errno.c.o.d
> -o
> tools/gollvm/libgo/CMakeFiles/libgo_c_piclib.dir/__/gofrontend/libgo/go/syscall/errno.c.o
>  -c /root/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/syscall/errno.c
>
> On Tuesday, May 26, 2020 at 8:41:18 PM UTC+8, Than McIntosh wrote:
>>
>> 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, May 26, 2020 at 7:21 AM Yuan Ting  wrote:
>>
>>> 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/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, 2020 at 10:15 PM Yuan Ting  wrote:

> 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 Ninja ../llvm
>
> and then build and install gollvm by
>
> ninja gollvm && ninja install-gollvm
>
> after a while, I encountered
>
> ...
>
> error: At most two relocations per offset are supported
>
> error: At most two relocations per offset are supported
>
> error: At most two relocations per offset are supported
>
> [212/1279] Creating
> /root/llvm-project/build-debug/tools/gollvm/libgo/tmp-sigtab.go
>
> FAILED: tools/gollvm/libgo/tmp-sigtab.go
>
> cd /root/llvm-project/build-debug/tools/gollvm/libgo && GOARCH=amd64
> GOOS=linux /bin/sh
> /root/llvm-project/llvm/tools/gollvm/libgo/capturescript.sh
> /root/llvm-project/llvm/tools/gollvm/gofrontend/libgo/mksigtab.sh
> /root/llvm-project/build-debug/tools/gollvm/libgo/tmp-sigtab.go
>
> error: no SHELL setting
>
> [214/1279] Creating
> /root/llvm-project/build-debug/tools/gollvm/libgo/tmp-sysinfo.go
>
> ninja: build stopped: subcommand failed.
>
>
> By add SHELL=/bin/sh, the errors above seems to be skipped but another
> period of time:
>
>
> ...
>
> /usr/bin/ld.gold: error:
> tools/gollvm/libgo/CMakeFiles/libgo_c_piclib.dir/__/gofrontend/libgo/go/syscall/errno.c.o:
> failed to match split-stack sequence at section 4 offset 0
>
> /usr/bin/ld.gold: error:
> tools/gollvm/libgo/CMakeFiles/libgo_c_piclib.dir/__/gofrontend/libgo/go/syscall/errno.c.o:
> failed to match split-stack sequence at section 6 offset 0
>
> /usr/bin/ld.gold: error:
> tools/gollvm/libgo/CMakeFiles/libgo_c_piclib.dir/__/gofrontend/libgo/go/syscall/signame.c.o:
> failed to match split-stack sequence at section 5 offset 0
>
> /usr/bin/ld.gold: error:
> 

Re: [go-nuts] Failed to build gollvm in a docker container

['Than McIntosh' via golang-nuts]

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, May 26, 2020 at 7:21 AM Yuan Ting  wrote:

> 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/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, 2020 at 10:15 PM Yuan Ting  wrote:
>>
>>> 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 Ninja ../llvm
>>>
>>> and then build and install gollvm by
>>>
>>> ninja gollvm && ninja install-gollvm
>>>
>>> after a while, I encountered
>>>
>>> ...
>>>
>>> error: At most two relocations per offset are supported
>>>
>>> error: At most two relocations per offset are supported
>>>
>>> error: At most two relocations per offset are supported
>>>
>>> [212/1279] Creating
>>> /root/llvm-project/build-debug/tools/gollvm/libgo/tmp-sigtab.go
>>>
>>> FAILED: tools/gollvm/libgo/tmp-sigtab.go
>>>
>>> cd /root/llvm-project/build-debug/tools/gollvm/libgo && GOARCH=amd64
>>> GOOS=linux /bin/sh
>>> /root/llvm-project/llvm/tools/gollvm/libgo/capturescript.sh
>>> /root/llvm-project/llvm/tools/gollvm/gofrontend/libgo/mksigtab.sh
>>> /root/llvm-project/build-debug/tools/gollvm/libgo/tmp-sigtab.go
>>>
>>> error: no SHELL setting
>>>
>>> [214/1279] Creating
>>> /root/llvm-project/build-debug/tools/gollvm/libgo/tmp-sysinfo.go
>>>
>>> ninja: build stopped: subcommand failed.
>>>
>>>
>>> By add SHELL=/bin/sh, the errors above seems to be skipped but another
>>> period of time:
>>>
>>>
>>> ...
>>>
>>> /usr/bin/ld.gold: error:
>>> tools/gollvm/libgo/CMakeFiles/libgo_c_piclib.dir/__/gofrontend/libgo/go/syscall/errno.c.o:
>>> failed to match split-stack sequence at section 4 offset 0
>>>
>>> /usr/bin/ld.gold: error:
>>> tools/gollvm/libgo/CMakeFiles/libgo_c_piclib.dir/__/gofrontend/libgo/go/syscall/errno.c.o:
>>> failed to match split-stack sequence at section 6 offset 0
>>>
>>> /usr/bin/ld.gold: error:
>>> tools/gollvm/libgo/CMakeFiles/libgo_c_piclib.dir/__/gofrontend/libgo/go/syscall/signame.c.o:
>>> failed to match split-stack sequence at section 5 offset 0
>>>
>>> /usr/bin/ld.gold: error:
>>> tools/gollvm/libgo/CMakeFiles/libbacktrace_piclib.dir/libbacktrace/backtrace.c.o:
>>> failed to match split-stack sequence at section 4 offset 0
>>>
>>> /usr/bin/ld.gold: error:
>>> tools/gollvm/libgo/CMakeFiles/libbacktrace_piclib.dir/libbacktrace/backtrace.c.o:
>>> failed to match split-stack sequence at section 6 offset 0
>>>
>>> /usr/bin/ld.gold: error:
>>> tools/gollvm/libgo/CMakeFiles/libbacktrace_piclib.dir/libbacktrace/dwarf.c.o:
>>> failed to match split-stack sequence at section 18 offset 0
>>>
>>> /usr/bin/ld.gold: error:
>>> tools/gollvm/libgo/CMakeFiles/libbacktrace_piclib.dir/libbacktrace/dwarf.c.o:
>>> failed to match split-stack sequence at section 79 offset 0
>>>
>>> ...
>>>
>>> /usr/bin/ld.gold: error:
>>> tools/gollvm/libgo/CMakeFiles/libffi_piclib.dir/libffi/src/x86/ffi64.c.o:
>>> failed to match split-stack sequence at section 22 offset 0
>>>
>>> /usr/bin/ld.gold: error:
>>> tools/gollvm/libgo/CMakeFiles/libffi_piclib.dir/libffi/src/x86/ffi64.c.o:
>>> failed to match split-stack sequence at section 26 offset 0
>>>
>>> /usr/bin/ld.gold: error:
>>> tools/gollvm/libgo/CMakeFiles/libffi_piclib.dir/libffi/src/x86/ffiw64.c.o:
>>> failed to match split-stack sequence at section 16 offset 0
>>>
>>> collect2: error: ld returned 1 exit status
>>>
>>> [901/1066] Linking C static library tools/gollvm/libgo/libgo.a
>>>
>>> ninja: build stopped: subcommand failed.
>>>
>>>
>>> I'm not sure the error is caused by the container environment or my
>>> configurations/other prerequisites.
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to golan...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/23309451-cb0a-4f7b-93a1-27038187302a%40googlegroups.com
>>> 
>>> .
>>>
>> --
> You received this message because you 

Re: [go-nuts] Failed to build gollvm in a docker container

['Than McIntosh' via golang-nuts]

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, 2020 at 10:15 PM Yuan Ting  wrote:

> 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
> Ninja ../llvm
>
> and then build and install gollvm by
>
> ninja gollvm && ninja install-gollvm
>
> after a while, I encountered
>
> ...
>
> error: At most two relocations per offset are supported
>
> error: At most two relocations per offset are supported
>
> error: At most two relocations per offset are supported
>
> [212/1279] Creating
> /root/llvm-project/build-debug/tools/gollvm/libgo/tmp-sigtab.go
>
> FAILED: tools/gollvm/libgo/tmp-sigtab.go
>
> cd /root/llvm-project/build-debug/tools/gollvm/libgo && GOARCH=amd64
> GOOS=linux /bin/sh
> /root/llvm-project/llvm/tools/gollvm/libgo/capturescript.sh
> /root/llvm-project/llvm/tools/gollvm/gofrontend/libgo/mksigtab.sh
> /root/llvm-project/build-debug/tools/gollvm/libgo/tmp-sigtab.go
>
> error: no SHELL setting
>
> [214/1279] Creating
> /root/llvm-project/build-debug/tools/gollvm/libgo/tmp-sysinfo.go
>
> ninja: build stopped: subcommand failed.
>
>
> By add SHELL=/bin/sh, the errors above seems to be skipped but another
> period of time:
>
>
> ...
>
> /usr/bin/ld.gold: error:
> tools/gollvm/libgo/CMakeFiles/libgo_c_piclib.dir/__/gofrontend/libgo/go/syscall/errno.c.o:
> failed to match split-stack sequence at section 4 offset 0
>
> /usr/bin/ld.gold: error:
> tools/gollvm/libgo/CMakeFiles/libgo_c_piclib.dir/__/gofrontend/libgo/go/syscall/errno.c.o:
> failed to match split-stack sequence at section 6 offset 0
>
> /usr/bin/ld.gold: error:
> tools/gollvm/libgo/CMakeFiles/libgo_c_piclib.dir/__/gofrontend/libgo/go/syscall/signame.c.o:
> failed to match split-stack sequence at section 5 offset 0
>
> /usr/bin/ld.gold: error:
> tools/gollvm/libgo/CMakeFiles/libbacktrace_piclib.dir/libbacktrace/backtrace.c.o:
> failed to match split-stack sequence at section 4 offset 0
>
> /usr/bin/ld.gold: error:
> tools/gollvm/libgo/CMakeFiles/libbacktrace_piclib.dir/libbacktrace/backtrace.c.o:
> failed to match split-stack sequence at section 6 offset 0
>
> /usr/bin/ld.gold: error:
> tools/gollvm/libgo/CMakeFiles/libbacktrace_piclib.dir/libbacktrace/dwarf.c.o:
> failed to match split-stack sequence at section 18 offset 0
>
> /usr/bin/ld.gold: error:
> tools/gollvm/libgo/CMakeFiles/libbacktrace_piclib.dir/libbacktrace/dwarf.c.o:
> failed to match split-stack sequence at section 79 offset 0
>
> ...
>
> /usr/bin/ld.gold: error:
> tools/gollvm/libgo/CMakeFiles/libffi_piclib.dir/libffi/src/x86/ffi64.c.o:
> failed to match split-stack sequence at section 22 offset 0
>
> /usr/bin/ld.gold: error:
> tools/gollvm/libgo/CMakeFiles/libffi_piclib.dir/libffi/src/x86/ffi64.c.o:
> failed to match split-stack sequence at section 26 offset 0
>
> /usr/bin/ld.gold: error:
> tools/gollvm/libgo/CMakeFiles/libffi_piclib.dir/libffi/src/x86/ffiw64.c.o:
> failed to match split-stack sequence at section 16 offset 0
>
> collect2: error: ld returned 1 exit status
>
> [901/1066] Linking C static library tools/gollvm/libgo/libgo.a
>
> ninja: build stopped: subcommand failed.
>
>
> I'm not sure the error is caused by the container environment or my
> configurations/other prerequisites.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/23309451-cb0a-4f7b-93a1-27038187302a%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BUr55G5Gndy7rDe%2BLLDQnxOm4gJxR-%2Bz%3DvU4YVx3GML%3D4Gsdg%40mail.gmail.com.

Re: [go-nuts] Build fails when following build instructions

['Than McIntosh' via golang-nuts]

>This seems to be the synchronization problem of gollvm and llvm, I am
fixing it today, if you have not done it, I can help.

Thanks, I have started a CL for this -- it is at
https://go-review.googlesource.com/c/gollvm/+/232497 if you want to look it
over. Not quite done yet, still a few things to wrap up.

Cheers, Than



On Wed, May 6, 2020 at 5:46 AM eric fang  wrote:

> This seems to be the synchronization problem of gollvm and llvm, I am
> fixing it today, if you have not done it, I can help.
>
> 在 2020年5月5日星期二 UTC+8下午8:30:14，Than McIntosh写道：
>>
>> OK, thanks for that.  I will investigate, this looks unrelated to the
>> previous problem. Stay tuned.
>>
>> Cheers, Than
>>
>>
>> On Tue, May 5, 2020 at 5:32 AM Martins Eglitis 
>> wrote:
>>
>> Hi,
>>
>> I am getting further now. This is what I am getting now:
>>
>> -- Could NOT find LibXml2 (missing: LIBXML2_LIBRARY LIBXML2_INCLUDE_DIR)
>> -- Native target architecture is X86
>> -- Threads enabled.
>> -- Doxygen disabled.
>> -- Go bindings disabled.
>> -- Ninja version: 1.10.0
>> -- Could NOT find OCaml (missing: OCAMLFIND OCAML_VERSION OCAML_STDLIB_PATH)
>> -- Could NOT find OCaml (missing: OCAMLFIND OCAML_VERSION OCAML_STDLIB_PATH)
>> -- OCaml bindings disabled.
>> -- LLVM host triple: x86_64-unknown-linux-gnu
>> -- LLVM default target triple: x86_64-unknown-linux-gnu
>> -- Building with -fPIC
>> -- Constructing LLVMBuild project information
>> -- Targeting X86
>> -- starting libgo configuration.
>> -- Libgo: creating stdlib package targets
>> -- Libgo: generating check targets
>> -- libgo configuration complete.
>> -- starting gotools configuration.
>> -- gotools: generating check targets
>> -- gotools configuration complete.
>> -- Registering Bye as a pass plugin (static build: OFF)
>> -- Failed to find LLVM FileCheck
>> -- Version: 0.0.0
>> -- Performing Test HAVE_GNU_POSIX_REGEX -- failed to compile
>> -- Performing Test HAVE_POSIX_REGEX -- success
>> -- Performing Test HAVE_STEADY_CLOCK -- success
>> -- Configuring done
>> -- Generating done
>> -- Build files have been written to: /home/gopher/workarea/build-debug
>> [1/1288] Linking CXX static library lib/libLLVMFrontendOpenMP.a
>> [2/1288] Linking CXX static library lib/libLLVMAggressiveInstCombine.a
>> [3/1288] Linking CXX static library lib/libLLVMLinker.a
>> [4/1288] Linking CXX static library lib/libLLVMVectorize.a
>> [5/1288] Building CXX object 
>> tools/gollvm/passes/CMakeFiles/LLVMCppGoPasses.dir/Util.cpp.o
>> FAILED: tools/gollvm/passes/CMakeFiles/LLVMCppGoPasses.dir/Util.cpp.o
>> /usr/bin/c++  -DGTEST_HAS_RTTI=0 -D_DEBUG -D_GNU_SOURCE 
>> -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS 
>> -Itools/gollvm/passes 
>> -I/home/gopher/workarea/llvm-project/llvm/tools/gollvm/passes -Iinclude 
>> -I/home/gopher/workarea/llvm-project/llvm/include -fcf-protection=none -fPIC 
>> -fvisibility-inlines-hidden -Werror=date-time -Wall -Wextra 
>> -Wno-unused-parameter -Wwrite-strings -Wcast-qual 
>> -Wno-missing-field-initializers -pedantic -Wno-long-long 
>> -Wimplicit-fallthrough -Wno-maybe-uninitialized -Wno-class-memaccess 
>> -Wno-redundant-move -Wno-noexcept-type -Wdelete-non-virtual-dtor 
>> -Wno-comment -fdiagnostics-color -g-fno-exceptions -fno-rtti -std=c++14 
>> -MD -MT tools/gollvm/passes/CMakeFiles/LLVMCppGoPasses.dir/Util.cpp.o -MF 
>> tools/gollvm/passes/CMakeFiles/LLVMCppGoPasses.dir/Util.cpp.o.d -o 
>> tools/gollvm/passes/CMakeFiles/LLVMCppGoPasses.dir/Util.cpp.o -c 
>> /home/gopher/workarea/llvm-project/llvm/tools/gollvm/passes/Util.cpp
>> /home/gopher/workarea/llvm-project/llvm/tools/gollvm/passes/Util.cpp: In 
>> function 'bool gollvm::passes::hasPointer(llvm::Type*)':
>> /home/gopher/workarea/llvm-project/llvm/tools/gollvm/passes/Util.cpp:34:14: 
>> error: 'VectorTyID' is not a member of 'llvm::Type'
>>34 |   case Type::VectorTyID:
>>   |  ^~
>> /home/gopher/workarea/llvm-project/llvm/tools/gollvm/passes/Util.cpp:35:26: 
>> error: 'class llvm::Type' has no member named 'getVectorElementType'; did 
>> you mean 'getPointerElementType'?
>>35 | return hasPointer(T->getVectorElementType());
>>   |  ^~~~
>>   |  getPointerElementType
>> /home/gopher/workarea/llvm-project/llvm/tools/gollvm/passes/Util.cpp: In 
>> function 'void getPtrBitmapForTypeHelper(llvm::Type*, const 
>> llvm::DataLayout&, uint64_t, llvm::BitVector&)':
>> /home/gopher/workarea/llvm-project/llvm/tools/gollvm/passes/Util.cpp:69:14: 
>> error: 'VectorTyID' is not a member of 'llvm::Type'
>>69 |   case Type::VectorTyID: {
>>   |  ^~
>> /home/gopher/workarea/llvm-project/llvm/tools/gollvm/passes/Util.cpp:70:19: 
>> error: 'class llvm::Type' has no member named 'getVectorElementType'; did 
>> you mean 'getPointerElementType'?
>>70 | Type *ET = T->getVectorElementType();
>>   |   ^~~~
>>   |   

Re: [go-nuts] Build fails when following build instructions

['Than McIntosh' via golang-nuts]

OK, thanks, that explains it.

When I compile the test file in question I get a prolog of

   0: 64 48 3b 24 25 70 00 cmp%fs:0x70,%rsp
   7: 00 00
   9: 73 12 jae1d 

Your prolog on the other hand looks like

   0:   f3 0f 1e fa *endbr64*
   4:   64 48 3b 24 25 70 00cmp%fs:0x70,%rsp
   b:   00 00
   d:   73 16   jae25 


Note the endbr64 -- this is coming from the GCC "-fcf-protection=branch"
command line option -- you aren't specifying this for your build, but most
likely it's being forced on intentionally by the provider of your linux
distro (or whoever built GCC), similar to the way some distros hard-wire on
PIE.

Thank you for reporting this problem.  I tested this scenario with tip of
trunk binutils and it looks as though it is still an issue. I will file a
binutils bug to report the issue and maybe also see about sending a fix if
I can.

In the mean time, one possible workaround would be for you to hard-wire off
this option in your Gollvm configure step.

Instead of running cmake as per the default installation instructions, you
can maybe try:

cmake -DCMAKE_BUILD_TYPE=Debug -DLLVM_USE_LINKER=gold
*-DCMAKE_CXX_FLAGS='-fcf-protection=none'
-DCMAKE_C_FLAGS='-fcf-protection=none'* -G Ninja ../llvm-project/llvm

to see if that gets things back on line for you.

Thanks, Than






On Mon, May 4, 2020 at 8:23 AM Martins Eglitis 
wrote:

> Here is the output:
>
> /tmp/CheckSymbolExists.o: file format elf64-x86-64
>
> SYMBOL TABLE:
>  ldf *ABS* CheckSymbolExists.c
>  ld  .text .text
>  ld  .data .data
>  ld  .bss  .bss
>  ld  .text.main    .text.main
>  ld  .note.GNU-split-stack 
> .note.GNU-split-stack
>  ld  .note.GNU-stack   .note.GNU-stack
>  ld  .note.gnu.property    
> .note.gnu.property
>  ld  .eh_frame .eh_frame
>  ld  .comment  .comment
>  g F .text.main   004b main
>  *UND* __morestack
>  *UND* _GLOBAL_OFFSET_TABLE_
>  *UND* mmap
>
>
>
> Disassembly of section .text.main:
>
>  :
> main():
>0: f3 0f 1e fa endbr64
>4: 64 48 3b 24 25 70 00cmp%fs:0x70,%rsp
>b: 00 00
>d: 73 16   jae25 
>f: 41 ba 08 00 00 00   mov$0x8,%r10d
>   15: 41 bb 00 00 00 00   mov$0x0,%r11d
>   1b: e8 00 00 00 00  callq  20 
>   1c: R_X86_64_PLT32  __morestack-0x4
>   20: c3  retq
>   21: f3 0f 1e fa endbr64
>   25: 55  push   %rbp
>   26: 48 89 e5mov%rsp,%rbp
>   29: 89 7d fcmov%edi,-0x4(%rbp)
>   2c: 48 89 75 f0 mov%rsi,-0x10(%rbp)
>   30: 8b 45 fcmov-0x4(%rbp),%eax
>   33: 48 98   cltq
>   35: 48 8d 14 85 00 00 00lea0x0(,%rax,4),%rdx
>   3c: 00
>   3d: 48 8b 05 00 00 00 00mov0x0(%rip),%rax# 44 
>   40: R_X86_64_REX_GOTPCRELX  mmap-0x4
>   44: 48 01 d0add%rdx,%rax
>   47: 8b 00   mov(%rax),%eax
>   49: 5d  pop%rbp
>   4a: c3  retq
>
> On 2020-05-04 14:43, Than McIntosh wrote:
>
> Thanks!
>
> Could you also please run
>
> objdump -tldr /tmp/CheckSymbolExists.o
>
> and send me the output of that?
>
> Cheers, Than
>
>
> On Mon, May 4, 2020 at 7:37 AM Martins Eglitis 
> wrote:
>
>> Hi,
>>
>> I am getting output like this:
>>
>> /tmp/CheckSymbolExists.c: In function 'main':
>> /tmp/CheckSymbolExists.c:7:11: warning: ISO C forbids conversion of function 
>> pointer to object pointer type [-Wpedantic]
>> 7 |   return ((int*)())[argc];
>>   |   ^
>> Using built-in specs.
>> COLLECT_GCC=/usr/bin/cc
>> COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper
>> OFFLOAD_TARGET_NAMES=nvptx-none:hsa
>> OFFLOAD_TARGET_DEFAULT=1
>> Target: x86_64-linux-gnu
>> Configured with: ../src/configure -v --with-pkgversion='Ubuntu 
>> 9.3.0-10ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs 
>> --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 
>> --prefix=/usr --with-gcc-major-version-only --program-suffix=-9 
>> --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id 
>> --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
>> --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug 
>> --enable-libstdcxx-time=yes 

Re: [go-nuts] Build fails when following build instructions

['Than McIntosh' via golang-nuts]

Thanks!

Could you also please run

objdump -tldr /tmp/CheckSymbolExists.o

and send me the output of that?

Cheers, Than


On Mon, May 4, 2020 at 7:37 AM Martins Eglitis 
wrote:

> Hi,
>
> I am getting output like this:
>
> /tmp/CheckSymbolExists.c: In function 'main':
> /tmp/CheckSymbolExists.c:7:11: warning: ISO C forbids conversion of function 
> pointer to object pointer type [-Wpedantic]
> 7 |   return ((int*)())[argc];
>   |   ^
> Using built-in specs.
> COLLECT_GCC=/usr/bin/cc
> COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper
> OFFLOAD_TARGET_NAMES=nvptx-none:hsa
> OFFLOAD_TARGET_DEFAULT=1
> Target: x86_64-linux-gnu
> Configured with: ../src/configure -v --with-pkgversion='Ubuntu 
> 9.3.0-10ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs 
> --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 --prefix=/usr 
> --with-gcc-major-version-only --program-suffix=-9 
> --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id 
> --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
> --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug 
> --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new 
> --enable-gnu-unique-object --disable-vtable-verify --enable-plugin 
> --enable-default-pie --with-system-zlib --with-target-system-zlib=auto 
> --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 
> --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib 
> --with-tune=generic --enable-offload-targets=nvptx-none,hsa 
> --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu 
> --host=x86_64-linux-gnu --target=x86_64-linux-gnu
> Thread model: posix
> gcc version 9.3.0 (Ubuntu 9.3.0-10ubuntu2)
> COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/9/:/usr/lib/gcc/x86_64-linux-gnu/9/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/9/:/usr/lib/gcc/x86_64-linux-gnu/
> LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/9/:/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/9/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/9/../../../:/lib/:/usr/lib/
> COLLECT_GCC_OPTIONS='-v' '-fPIC' '-fsplit-stack' '-fuse-ld=gold' '-o' 
> '/tmp/a.out' '-mtune=generic' '-march=x86-64'
>  /usr/lib/gcc/x86_64-linux-gnu/9/collect2 -plugin 
> /usr/lib/gcc/x86_64-linux-gnu/9/liblto_plugin.so 
> -plugin-opt=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper 
> -plugin-opt=-fresolution=/tmp/ccoxuoxd.res -plugin-opt=-pass-through=-lgcc 
> -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc 
> -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --build-id 
> --eh-frame-hdr -m elf_x86_64 --hash-style=gnu --as-needed -dynamic-linker 
> /lib64/ld-linux-x86-64.so.2 -pie -z now -fuse-ld=gold -z relro -o /tmp/a.out 
> /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/Scrt1.o 
> /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/crti.o 
> /usr/lib/gcc/x86_64-linux-gnu/9/crtbeginS.o -L/usr/lib/gcc/x86_64-linux-gnu/9 
> -L/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu 
> -L/usr/lib/gcc/x86_64-linux-gnu/9/../../../../lib -L/lib/x86_64-linux-gnu 
> -L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib 
> -L/usr/lib/gcc/x86_64-linux-gnu/9/../../.. -allow-shlib-undefined --debug all 
> /tmp/CheckSymbolExists.o -lm --wrap=pthread_create -lgcc --push-state 
> --as-needed -lgcc_s --pop-state -lc -lgcc --push-state --as-needed -lgcc_s 
> --pop-state /usr/lib/gcc/x86_64-linux-gnu/9/crtendS.o 
> /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/crtn.o
> /usr/bin/ld.gold: recording to gold-recording-26rMUl
> /usr/bin/ld.gold:   0 running   task Dir_cache_task 
> /usr/lib/gcc/x86_64-linux-gnu/9
> /usr/bin/ld.gold:   0 completed task Dir_cache_task 
> /usr/lib/gcc/x86_64-linux-gnu/9 (user: 0.00 sys: 0.00 wall: 0.00)
> /usr/bin/ld.gold:   0 running   task Dir_cache_task 
> /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu
> /usr/bin/ld.gold:   0 completed task Dir_cache_task 
> /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu (user: 0.00 
> sys: 0.00 wall: 0.00)
> /usr/bin/ld.gold:   0 running   task Dir_cache_task 
> /usr/lib/gcc/x86_64-linux-gnu/9/../../../../lib
> /usr/bin/ld.gold:   0 completed task Dir_cache_task 
> /usr/lib/gcc/x86_64-linux-gnu/9/../../../../lib (user: 0.00 sys: 0.00 
> wall: 0.00)
> /usr/bin/ld.gold:   0 running   task Dir_cache_task /lib/x86_64-linux-gnu
> /usr/bin/ld.gold:   0 completed task Dir_cache_task /lib/x86_64-linux-gnu 
> (user: 0.00 sys: 0.00 wall: 0.01)
> /usr/bin/ld.gold:   0 running   task Dir_cache_task /lib/../lib
> /usr/bin/ld.gold:   0 completed task Dir_cache_task /lib/../lib (user: 
> 0.00 sys: 0.00 wall: 0.00)
> /usr/bin/ld.gold:   0 running   task Dir_cache_task /usr/lib/x86_64-linux-gnu
> 

Re: [go-nuts] Build fails when following build instructions

['Than McIntosh' via golang-nuts]

Sorry, I wasn't clear on that last email.

What I'm asking is if you could rerun the compilation by hand, e.g.

$ cat > /tmp/CheckSymbolExists.c << EOF
#include 

int main(int argc, char** argv)
{
  (void)argv;
#ifndef mmap
  return ((int*)())[argc];
#else
  (void)argc;
  return 0;
#endif
}
EOF
$ /usr/bin/cc -fPIC -Werror=date-time -Wall -Wextra -Wno-unused-parameter
-Wwrite-strings -Wno-missing-field-initializers -pedantic -Wno-long-long
-Wimplicit-fallthrough -Wno-comment -fdiagnostics-color -ffunction-sections
-fdata-sections -fuse-ld=gold -fsplit-stack  -fuse-ld=gold
-Wl,-allow-shlib-undefined /tmp/CheckSymbolExists.c -c -o
/tmp/CheckSymbolExists.o
$ /usr/bin/cc -v -fPIC -fuse-ld=gold -fsplit-stack  -fuse-ld=gold
-Wl,-allow-shlib-undefined -Wl,--debug,all  /tmp/CheckSymbolExists.o -o
/tmp/a.out  -lm
$

I am hoping that might give me a little more info.

Thanks, Than


On Fri, May 1, 2020 at 9:41 AM Martins Eglitis 
wrote:

> Sure, I have attached the CMakeOutput.log and CMakeError.log
> On 2020-05-01 16:19, Than McIntosh wrote:
>
>
> A little more detail on the error in question. This is a very obscure
> error, so please bear with me.
>
> >>/usr/bin/ld.gold: error:
> CMakeFiles/cmTC_81c99.dir/CheckSymbolExists.c.o: failed to match
> split-stack sequence at section 4 offset 0
>
> What's happening here is that the linker (ld.gold) is linking together two
> object files, let's call them "a.o" and "b.o".
>
> The linker detects that one of the objects (let's say "a.o") has a marker
> indicating that it was compiled with the "-fsplit-stack" option. The second
> object file "b.o" has no such marker (e.g. it apparently wasn't compiled
> with -fsplit-stack).
>
> In addition, the linker sees (from object file relocations) that a
> function (let's call it AFunc) in a.o is making a call to BFunc in b.o. In
> such instances the gold linker has a feature that will perform a
> fixup/rewrite on the calling function to make sure that when the call takes
> place, the stack is large enough (so that -split-stack will have the right
> effect).
>
> To apply this fixup, the linker is looking for a specific prolog
> instruction sequence-- when it doesn't find that sequence, it issues the
> error.
>
> In the previous LLVM bug I cited, the problem was with the C compiler --
> it was marking the object as split-stack, but not consistently emitting the
> prolog sequence that the linker looks for.
>
> Your compiler is an up-to-date version of GCC, however, so it's hard for
> me to believe that the compiler is at fault.
>
> [This is a lot of technical detail, sorry about that].
>
> Do you think you could rerun the compile by hand and send me some of the
> output (e.g. regenerate the file "CheckSymbolExists.c" as it appeared in
> the cmake output log?
>
> Thanks, Than
>
> On Thu, Apr 30, 2020 at 4:39 PM Martins Eglitis 
> wrote:
>
>> Sorry, I should have mentioned that I am running a docker container based
>> on the latest Ubuntu, and Ubuntu 18.04 as the host.
>>
>> On April 30, 2020 11:37:15 PM GMT+03:00, Martins Eglitis <
>> mart...@sitilge.id.lv> wrote:
>>>
>>> Yes,
>>>
>>> cc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
>>>
>>>
>>> On April 30, 2020 11:29:07 PM GMT+03:00, Than McIntosh 
>>> wrote:

 >>/usr/bin/ld.gold: error: CMakeFiles/cmTC_81c99.dir/CheckSymbolExists.c.o:
 failed to match split-stack sequence at section 4 offset 0

 OK, now I think we're getting somewhere, this looks suspicious.  For
 reference, could you please send me the output of "/usr/bin/cc --version"?

 Thanks, Than




 On Thu, Apr 30, 2020 at 4:26 PM Martins Eglitis 
 wrote:

> Hi,
>
> There was something related in "CMakeError.log":
>
> Determining if the mmap exist failed with the following output:
> Change Dir: /home/gopher/workarea/build-debug/CMakeFiles/CMakeTmp
>
> Run Build Command(s):/usr/bin/ninja cmTC_81c99 && [1/2] Building C object 
> CMakeFiles/cmTC_81c99.dir/CheckSymbolExists.c.o
> CheckSymbolExists.c: In function 'main':
> CheckSymbolExists.c:8:11: warning: ISO C forbids conversion of function 
> pointer to object pointer type [-Wpedantic]
> 8 |   return ((int*)())[argc];
>   |   ^
> [2/2] Linking C executable cmTC_81c99
> FAILED: cmTC_81c99
> : && /usr/bin/cc -fPIC -Werror=date-time -Wall -Wextra 
> -Wno-unused-parameter -Wwrite-strings -Wno-missing-field-initializers 
> -pedantic -Wno-long-long -Wimplicit-fallthrough -Wno-comment 
> -fdiagnostics-color -ffunction-sections -fdata-sections -fuse-ld=gold 
> -fsplit-stack  -fuse-ld=gold -Wl,-allow-shlib-undefined 
> CMakeFiles/cmTC_81c99.dir/CheckSymbolExists.c.o  -o cmTC_81c99  -lm && :
> /usr/bin/ld.gold: error: CMakeFiles/cmTC_81c99.dir/CheckSymbolExists.c.o: 
> failed to match split-stack sequence at section 4 offset 0
> collect2: error: ld returned 1 exit status
> ninja: build stopped: subcommand failed.
>

Re: [go-nuts] Build fails when following build instructions

['Than McIntosh' via golang-nuts]

A little more detail on the error in question. This is a very obscure
error, so please bear with me.

>>/usr/bin/ld.gold: error: CMakeFiles/cmTC_81c99.dir/CheckSymbolExists.c.o:
failed to match split-stack sequence at section 4 offset 0

What's happening here is that the linker (ld.gold) is linking together two
object files, let's call them "a.o" and "b.o".

The linker detects that one of the objects (let's say "a.o") has a marker
indicating that it was compiled with the "-fsplit-stack" option. The second
object file "b.o" has no such marker (e.g. it apparently wasn't compiled
with -fsplit-stack).

In addition, the linker sees (from object file relocations) that a function
(let's call it AFunc) in a.o is making a call to BFunc in b.o. In such
instances the gold linker has a feature that will perform a fixup/rewrite
on the calling function to make sure that when the call takes place, the
stack is large enough (so that -split-stack will have the right effect).

To apply this fixup, the linker is looking for a specific prolog
instruction sequence-- when it doesn't find that sequence, it issues the
error.

In the previous LLVM bug I cited, the problem was with the C compiler -- it
was marking the object as split-stack, but not consistently emitting the
prolog sequence that the linker looks for.

Your compiler is an up-to-date version of GCC, however, so it's hard for me
to believe that the compiler is at fault.

[This is a lot of technical detail, sorry about that].

Do you think you could rerun the compile by hand and send me some of the
output (e.g. regenerate the file "CheckSymbolExists.c" as it appeared in
the cmake output log?

Thanks, Than

On Thu, Apr 30, 2020 at 4:39 PM Martins Eglitis 
wrote:

> Sorry, I should have mentioned that I am running a docker container based
> on the latest Ubuntu, and Ubuntu 18.04 as the host.
>
> On April 30, 2020 11:37:15 PM GMT+03:00, Martins Eglitis <
> mart...@sitilge.id.lv> wrote:
>>
>> Yes,
>>
>> cc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
>>
>>
>> On April 30, 2020 11:29:07 PM GMT+03:00, Than McIntosh 
>> wrote:
>>>
>>> >>/usr/bin/ld.gold: error: CMakeFiles/cmTC_81c99.dir/CheckSymbolExists.c.o:
>>> failed to match split-stack sequence at section 4 offset 0
>>>
>>> OK, now I think we're getting somewhere, this looks suspicious.  For
>>> reference, could you please send me the output of "/usr/bin/cc --version"?
>>>
>>> Thanks, Than
>>>
>>>
>>>
>>>
>>> On Thu, Apr 30, 2020 at 4:26 PM Martins Eglitis 
>>> wrote:
>>>
 Hi,

 There was something related in "CMakeError.log":

 Determining if the mmap exist failed with the following output:
 Change Dir: /home/gopher/workarea/build-debug/CMakeFiles/CMakeTmp

 Run Build Command(s):/usr/bin/ninja cmTC_81c99 && [1/2] Building C object 
 CMakeFiles/cmTC_81c99.dir/CheckSymbolExists.c.o
 CheckSymbolExists.c: In function 'main':
 CheckSymbolExists.c:8:11: warning: ISO C forbids conversion of function 
 pointer to object pointer type [-Wpedantic]
 8 |   return ((int*)())[argc];
   |   ^
 [2/2] Linking C executable cmTC_81c99
 FAILED: cmTC_81c99
 : && /usr/bin/cc -fPIC -Werror=date-time -Wall -Wextra 
 -Wno-unused-parameter -Wwrite-strings -Wno-missing-field-initializers 
 -pedantic -Wno-long-long -Wimplicit-fallthrough -Wno-comment 
 -fdiagnostics-color -ffunction-sections -fdata-sections -fuse-ld=gold 
 -fsplit-stack  -fuse-ld=gold -Wl,-allow-shlib-undefined 
 CMakeFiles/cmTC_81c99.dir/CheckSymbolExists.c.o  -o cmTC_81c99  -lm && :
 /usr/bin/ld.gold: error: CMakeFiles/cmTC_81c99.dir/CheckSymbolExists.c.o: 
 failed to match split-stack sequence at section 4 offset 0
 collect2: error: ld returned 1 exit status
 ninja: build stopped: subcommand failed.


 File 
 /home/gopher/workarea/build-debug/CMakeFiles/CMakeTmp/CheckSymbolExists.c:
 /* */
 #include 

 int main(int argc, char** argv)
 {
   (void)argv;
 #ifndef mmap
   return ((int*)())[argc];
 #else
   (void)argc;
   return 0;
 #endif
 }

 On 2020-04-30 20:32, Than McIntosh wrote:

 Thanks for the email.

 Sorry for the delay in responding, this is a very busy time right now
 for our team (release freeze is happening at the end of this week).

 Just in general, the gollvm build procedure uses "cmake", and as part
 of this process cmake is running various tests to make sure that the C
 compiler you're using works properly, and to detect whether the system you
 are building on has the right header files, libraries, etc.

 Of particular concern is the cmake check for "mmap"-- the mmap()
 routine is definitely available on Ubuntu, so it's puzzling that cmake
 thinks it isn't available.

 One thing you might do: after the build fails, try looking at the
 debris in the CMakeFiles dir:

 $ ls CMakeFiles
 3.13.4 

Re: [go-nuts] Build fails when following build instructions

['Than McIntosh' via golang-nuts]

>>/usr/bin/ld.gold: error: CMakeFiles/cmTC_81c99.dir/CheckSymbolExists.c.o:
failed to match split-stack sequence at section 4 offset 0

OK, now I think we're getting somewhere, this looks suspicious.  For
reference, could you please send me the output of "/usr/bin/cc --version"?

Thanks, Than




On Thu, Apr 30, 2020 at 4:26 PM Martins Eglitis 
wrote:

> Hi,
>
> There was something related in "CMakeError.log":
>
> Determining if the mmap exist failed with the following output:
> Change Dir: /home/gopher/workarea/build-debug/CMakeFiles/CMakeTmp
>
> Run Build Command(s):/usr/bin/ninja cmTC_81c99 && [1/2] Building C object 
> CMakeFiles/cmTC_81c99.dir/CheckSymbolExists.c.o
> CheckSymbolExists.c: In function 'main':
> CheckSymbolExists.c:8:11: warning: ISO C forbids conversion of function 
> pointer to object pointer type [-Wpedantic]
> 8 |   return ((int*)())[argc];
>   |   ^
> [2/2] Linking C executable cmTC_81c99
> FAILED: cmTC_81c99
> : && /usr/bin/cc -fPIC -Werror=date-time -Wall -Wextra -Wno-unused-parameter 
> -Wwrite-strings -Wno-missing-field-initializers -pedantic -Wno-long-long 
> -Wimplicit-fallthrough -Wno-comment -fdiagnostics-color -ffunction-sections 
> -fdata-sections -fuse-ld=gold -fsplit-stack  -fuse-ld=gold 
> -Wl,-allow-shlib-undefined CMakeFiles/cmTC_81c99.dir/CheckSymbolExists.c.o  
> -o cmTC_81c99  -lm && :
> /usr/bin/ld.gold: error: CMakeFiles/cmTC_81c99.dir/CheckSymbolExists.c.o: 
> failed to match split-stack sequence at section 4 offset 0
> collect2: error: ld returned 1 exit status
> ninja: build stopped: subcommand failed.
>
>
> File 
> /home/gopher/workarea/build-debug/CMakeFiles/CMakeTmp/CheckSymbolExists.c:
> /* */
> #include 
>
> int main(int argc, char** argv)
> {
>   (void)argv;
> #ifndef mmap
>   return ((int*)())[argc];
> #else
>   (void)argc;
>   return 0;
> #endif
> }
>
> On 2020-04-30 20:32, Than McIntosh wrote:
>
> Thanks for the email.
>
> Sorry for the delay in responding, this is a very busy time right now for
> our team (release freeze is happening at the end of this week).
>
> Just in general, the gollvm build procedure uses "cmake", and as part of
> this process cmake is running various tests to make sure that the C
> compiler you're using works properly, and to detect whether the system you
> are building on has the right header files, libraries, etc.
>
> Of particular concern is the cmake check for "mmap"-- the mmap() routine
> is definitely available on Ubuntu, so it's puzzling that cmake thinks it
> isn't available.
>
> One thing you might do: after the build fails, try looking at the debris
> in the CMakeFiles dir:
>
> $ ls CMakeFiles
> 3.13.4 cmake.check_cache  feature_tests.bin  src.c
> 3.15.4 CMakeError.log feature_tests.c
>  TargetDirectories.txt
> CheckIncludeFiles  CMakeOutput.logfeature_tests.cxx  test.o
> CheckTypeSize  CMakeTmp   simple.cc
>
> In that dir, look at "CMakeOutput.log" for the place where this test is
> run:
>
> Look for a section that looks like this:
>
> Determining if the mmap exist passed with the following output:
> Change Dir: /tmp/llvm-project/build-relwithdbg/CMakeFiles/CMakeTmp
>
> Run Build Command:"/usr/local/google/home/thanm/bin/ninja" "cmTC_feb45"
> [1/2] Building C object CMakeFiles/cmTC_feb45.dir/CheckSymbolExists.c.o
> CheckSymbolExists.c: In function ‘main’:
> CheckSymbolExists.c:8:11: warning: ISO C forbids conversion of
> function pointer to object pointer type [-Wpedantic]
>return ((int*)())[argc];
>   ^
> [2/2] Linking C executable cmTC_feb45
>
> File
> /tmp/llvm-project/build-relwithdbg/CMakeFiles/CMakeTmp/CheckSymbolExists.c:
> /* */
> #include 
>
> int main(int argc, char** argv)
> {
>   (void)argv;
> #ifndef mmap
>   return ((int*)())[argc];
> #else
>   (void)argc;
>   return 0;
> #endif
> }
>
> Are there any clues there perhaps?
>
> Thanks, Than
>
>
> On Thu, Apr 30, 2020 at 1:05 PM  wrote:
>
>> Hi,
>>
>> I initially opened an issue, but was suggested to post to the mailing
>> list instead: https://github.com/golang/go/issues/38728
>>
>> Build keeps failing when trying to build (Ubuntu Focal Fossa, amd64) from
>> the latest commit to the master and following the build instructions. Has
>> anyone succeeded to build gollvm recently? I am getting errors like this:
>>
>> -- Could NOT find LibXml2 (missing: LIBXML2_LIBRARY LIBXML2_INCLUDE_DIR)
>> -- Native target architecture is X86
>> -- Threads enabled.
>> -- Doxygen disabled.
>> -- Go bindings disabled.
>> -- Ninja version: 1.10.0
>> -- Could NOT find OCaml (missing: OCAMLFIND OCAML_VERSION OCAML_STDLIB_PATH)
>> -- Could NOT find OCaml (missing: OCAMLFIND OCAML_VERSION OCAML_STDLIB_PATH)
>> -- OCaml bindings disabled.
>> -- LLVM host triple: x86_64-unknown-linux-gnu
>> -- LLVM default target triple: x86_64-unknown-linux-gnu
>> -- Building with -fPIC
>> -- Constructing LLVMBuild project information
>> -- 

Re: [go-nuts] Build fails when following build instructions

['Than McIntosh' via golang-nuts]

Thanks for the email.

Sorry for the delay in responding, this is a very busy time right now for
our team (release freeze is happening at the end of this week).

Just in general, the gollvm build procedure uses "cmake", and as part of
this process cmake is running various tests to make sure that the C
compiler you're using works properly, and to detect whether the system you
are building on has the right header files, libraries, etc.

Of particular concern is the cmake check for "mmap"-- the mmap() routine is
definitely available on Ubuntu, so it's puzzling that cmake thinks it isn't
available.

One thing you might do: after the build fails, try looking at the debris in
the CMakeFiles dir:

$ ls CMakeFiles
3.13.4 cmake.check_cache  feature_tests.bin  src.c
3.15.4 CMakeError.log feature_tests.c
 TargetDirectories.txt
CheckIncludeFiles  CMakeOutput.logfeature_tests.cxx  test.o
CheckTypeSize  CMakeTmp   simple.cc

In that dir, look at "CMakeOutput.log" for the place where this test is run:

Look for a section that looks like this:

Determining if the mmap exist passed with the following output:
Change Dir: /tmp/llvm-project/build-relwithdbg/CMakeFiles/CMakeTmp

Run Build Command:"/usr/local/google/home/thanm/bin/ninja" "cmTC_feb45"
[1/2] Building C object CMakeFiles/cmTC_feb45.dir/CheckSymbolExists.c.o
CheckSymbolExists.c: In function ‘main’:
CheckSymbolExists.c:8:11: warning: ISO C forbids conversion of function
pointer to object pointer type [-Wpedantic]
   return ((int*)())[argc];
  ^
[2/2] Linking C executable cmTC_feb45

File
/tmp/llvm-project/build-relwithdbg/CMakeFiles/CMakeTmp/CheckSymbolExists.c:
/* */
#include 

int main(int argc, char** argv)
{
  (void)argv;
#ifndef mmap
  return ((int*)())[argc];
#else
  (void)argc;
  return 0;
#endif
}

Are there any clues there perhaps?

Thanks, Than


On Thu, Apr 30, 2020 at 1:05 PM  wrote:

> Hi,
>
> I initially opened an issue, but was suggested to post to the mailing list
> instead: https://github.com/golang/go/issues/38728
>
> Build keeps failing when trying to build (Ubuntu Focal Fossa, amd64) from
> the latest commit to the master and following the build instructions. Has
> anyone succeeded to build gollvm recently? I am getting errors like this:
>
> -- Could NOT find LibXml2 (missing: LIBXML2_LIBRARY LIBXML2_INCLUDE_DIR)
> -- Native target architecture is X86
> -- Threads enabled.
> -- Doxygen disabled.
> -- Go bindings disabled.
> -- Ninja version: 1.10.0
> -- Could NOT find OCaml (missing: OCAMLFIND OCAML_VERSION OCAML_STDLIB_PATH)
> -- Could NOT find OCaml (missing: OCAMLFIND OCAML_VERSION OCAML_STDLIB_PATH)
> -- OCaml bindings disabled.
> -- LLVM host triple: x86_64-unknown-linux-gnu
> -- LLVM default target triple: x86_64-unknown-linux-gnu
> -- Building with -fPIC
> -- Constructing LLVMBuild project information
> -- Targeting AArch64
> -- Targeting AMDGPU
> -- Targeting ARM
> -- Targeting AVR
> -- Targeting BPF
> -- Targeting Hexagon
> -- Targeting Lanai
> -- Targeting Mips
> -- Targeting MSP430
> -- Targeting NVPTX
> -- Targeting PowerPC
> -- Targeting RISCV
> -- Targeting Sparc
> -- Targeting SystemZ
> -- Targeting WebAssembly
> -- Targeting X86
> -- Targeting XCore
> CMake Error at tools/gollvm/cmake/modules/AddGollvm.cmake:37 (message):
>   C compiler does not support -fsplit-stack
> Call Stack (most recent call first):
>   tools/gollvm/CMakeLists.txt:21 (include)
>
>
> -- starting libgo configuration.
> CMake Error at tools/gollvm/cmake/modules/LibbacktraceUtils.cmake:19 
> (message):
>   Support for mmap() is required -- setup failed.
> Call Stack (most recent call first):
>   tools/gollvm/libgo/CMakeLists.txt:45 (setup_libbacktrace)
>
>
> CMake Error at tools/gollvm/cmake/modules/LibffiUtils.cmake:27 (message):
>   Support for mmap() is required -- setup failed.
> Call Stack (most recent call first):
>   tools/gollvm/libgo/CMakeLists.txt:49 (setup_libffi)
>
>
> -- Libgo: creating stdlib package targets
> -- Libgo: generating check targets
> -- libgo configuration complete.
> -- starting gotools configuration.
> -- gotools: generating check targets
> -- gotools configuration complete.
> -- Registering Bye as a pass plugin (static build: OFF)
> -- Failed to find LLVM FileCheck
> -- Version: 0.0.0
> -- Performing Test HAVE_GNU_POSIX_REGEX -- failed to compile
> -- Performing Test HAVE_POSIX_REGEX -- success
> -- Performing Test HAVE_STEADY_CLOCK -- success
> -- Configuring incomplete, errors occurred!
> See also "/home/gopher/workarea/build-debug/CMakeFiles/CMakeOutput.log".
> See also "/home/gopher/workarea/build-debug/CMakeFiles/CMakeError.log".
> ninja: error: loading 'build.ninja': No such file or directory
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to 

Re: [go-nuts] Gollvm, some questions

['Than McIntosh' via golang-nuts]

Hi,

Thanks for your note.

The big picture is that gollvm is still very much an experimental version
of Go; we take care of it and keep it operating at a basic level, but it
can be unstable at times. Worth adding that development activity on Gollvm
is mostly paused at the moment while Cherry and I are working on other
things; depending on how things go we may "un-pause" at some point in the
future, but it's hard to predict.

Your questions in particular:

>1) Are there any special blog or news feed dedicated to gollvm?

We don't have a separate blog/newsfeed; for questions and discussion we
just use the regular go-nuts mailing list.

2) How to choose version of llvm for gollvm? For example, is it possible to
take llvm-9.0 for current version of gollvm? What is the algorithm of
version's selection?

There isn't a version selection algorithm per se. At any given point in
time, gollvm "tip of master branch" is intended to work with LLVM tip of
master branch. There will occasionally be changes made to the LLVM apis
that will break the gollvm build; when we notice this happening we try to
check in fixes to sync up.

>3) What are the immediate plans in gollvm? What users of gollvm can
expect? Will be this projects developed in long term?

There aren't any immediate plans, and as mentioned previously things are
still in an experimental mode-- sorry I can't be more specific.

While gollvm is in a reasonably useable state, there are still a lot of
cool things that we could be doing with it but haven't (since we haven't
had the time). For example, it would be interesting to get AutoFDO and/or
Thin LTO working with gollvm, or work figuring out how to integrate it with
the LLVM JIT, that sort of thing.

Hope this helps--

Cheers, Than

On Tue, Apr 21, 2020 at 7:42 PM Ian Lance Taylor  wrote:

> [ +Than McIntosh +Cherry Zhang ]
>
> On Tue, Apr 21, 2020 at 4:19 PM  wrote:
> >
> > I am interesting in gollvm project and would like to ask some questions
> about gollvm.
> > 1) Are there any special blog or news feed dedicated to gollvm?
> > 2) How to choose version of llvm for gollvm? For example, is it possible
> to take llvm-9.0 for current version of gollvm? What is the algorithm of
> version's selection?
> > 3) What are the immediate plans in gollvm? What users of gollvm can
> expect? Will be this projects developed in long term?
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "golang-nuts" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to golang-nuts+unsubscr...@googlegroups.com.
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/81bf1c16-b832-42c8-b153-0c4381e64c2c%40googlegroups.com
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BUr55Hm9WzB%3DoGi0UHtfzJCn%2BSoBSXucheJJy8f2w6FRoYJpA%40mail.gmail.com.

Re: [go-nuts] go1.14/go1.14.1 missing some debug information

['Than McIntosh' via golang-nuts]

Thanks for filing the issue (https://github.com/golang/go/issues/38192). I
added some comments.

On Wed, Apr 1, 2020 at 12:46 AM Ian Lance Taylor  wrote:

> On Tue, Mar 31, 2020 at 5:19 PM sanye  wrote:
> >
> > Hello gophers,
> >   I have a problem when debugging with gdb using go1.14/1.14.1, set a
> breakpoint on entrypoint will not show line and file information, but
> go1.13.9 and older versions have, here is the detail
> >
> >   demo.go
> > 
> > package main
> >
> > func main() {
> > println("hello world")
> > }
> >
> > build
> > 
> > go build -gcflags "all=-N -l" demo.go
> >
> > go1.13.9
> > -
> > $ go version
> > go version go1.13.9 linux/amd64
> > $ go build -gcflags "all=-N -l" demo.go
> > $ gdb ./demo
> > ...
> > (gdb) info files
> > Symbols from "/dev/shm/ex/demo".
> > Local exec file:
> > `/dev/shm/ex/demo', file type elf64-x86-64.
> > Entry point: 0x4542a0
> > ...
> > (gdb) b *0x4542a0
> > Breakpoint 1 at 0x4542a0: file
> /dev/shm/ex/go/src/runtime/rt0_linux_amd64.s, line 8.
> >
> > go1.14/go1.14.1
> > 
> > $ go version
> > go version go1.14.1 linux/amd64
> > $ go build -gcflags "all=-N -l" demo.go
> > $ gdb ./demo
> > ...
> > (gdb) info files
> > Symbols from "/dev/shm/ex/demo".
> > Local exec file:
> > `/dev/shm/ex/demo', file type elf64-x86-64.
> > Entry point: 0x45cdd0
> > ...
> > (gdb) b *0x45cdd0
> > Breakpoint 1 at 0x45cdd0
> >
> > any help would be appreciated
>
> Odd.  I can recreate this, but I don't know what is going on here.
> Please open a bug report at https://golang.org/issue.  Thanks.
>
> Ian
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAOyqgcWwbswFmYZmBV5vto9gvP%2Bn_ufw8VR1D9sGL38CX0rn_g%40mail.gmail.com
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BUr55ET35%2B6eFELrtiRcmRAoGbGOgb2hx7AwfFMmmowLd-bew%40mail.gmail.com.

Re: [go-nuts] [gollvm] Cannot build project : no type named 'CompositeType' in namespace 'llvm'

['Than McIntosh' via golang-nuts]

CL submitted. If you can please update your client and try your build
again, it should go through.

Thanks, Than

On Tue, Mar 31, 2020 at 2:56 PM Than McIntosh  wrote:

> Hello again,
>
> The gollvm sources were indeed out of date with LLVM tip. I sent
>
> https://go-review.googlesource.com/c/gollvm/+/226637
>
> to resolve the problem. I'll let you know when this is checked in.
>
> Thanks, Than
>
>
> On Tue, Mar 31, 2020 at 12:40 PM Than McIntosh  wrote:
>
>> Hi,
>>
>> I'll take a look to see if I can reproduce the problem.
>>
>> Gollvm is "out of tree", meaning that when LLVM headers and data
>> structures change things can get out of sync, but I'll need to confirm.
>>
>> Thanks, Than
>>
>>
>>
>> On Tue, Mar 31, 2020 at 12:16 PM Ian Lance Taylor 
>> wrote:
>>
>>> [ + thanm, cherryyz ]
>>>
>>> On Tue, Mar 31, 2020 at 9:03 AM  wrote:
>>> >
>>> > Hi,
>>> >
>>> > I am currently trying to build the gollvm compiler.
>>> > I have followed the instructions provided on the Google source page,
>>> up until the "ninja gollvm" instruction, the only difference being that my
>>> workarea folder is named build-gollvm. At this point, I get the following
>>> error :
>>> >
>>> >> [1/1243] Building CXX object
>>> tools/gol...pGoFrontEnd.dir/go-llvm-builtins.cpp.o
>>> >> FAILED:
>>> tools/gollvm/bridge/CMakeFiles/LLVMCppGoFrontEnd.dir/go-llvm-builtins.cpp.o
>>> >> /usr/bin/c++  -DGTEST_HAS_RTTI=0 -D_DEBUG -D_GNU_SOURCE
>>> -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
>>> -Itools/gollvm/bridge -I/home/jeremy/llvm-project/llvm/tools/gollvm/bridge
>>> -Iinclude -I/home/jeremy/llvm-project/llvm/include
>>> -Itools/gollvm/external/install/include
>>> -I/home/jeremy/llvm-project/llvm/tools/gollvm/gofrontend/go -fPIC
>>> -fvisibility-inlines-hidden -Werror=date-time
>>> -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter
>>> -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic
>>> -Wno-long-long -Wimplicit-fallthrough -Wcovered-switch-default
>>> -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor
>>> -Wno-comment -Wstring-conversion -fdiagnostics-color -g-fno-exceptions
>>> -fno-rtti -std=c++14 -MD -MT
>>> tools/gollvm/bridge/CMakeFiles/LLVMCppGoFrontEnd.dir/go-llvm-builtins.cpp.o
>>> -MF
>>> tools/gollvm/bridge/CMakeFiles/LLVMCppGoFrontEnd.dir/go-llvm-builtins.cpp.o.d
>>> -o
>>> tools/gollvm/bridge/CMakeFiles/LLVMCppGoFrontEnd.dir/go-llvm-builtins.cpp.o
>>> -c /home/jeremy/llvm-project/llvm/tools/gollvm/bridge/go-llvm-builtins.cpp
>>> >> In file included from
>>> /home/jeremy/llvm-project/llvm/tools/gollvm/bridge/go-llvm-builtins.cpp:13:
>>> >> /home/jeremy/llvm-project/llvm/tools/gollvm/bridge/go-llvm.h:463:45:
>>> error: no type named 'CompositeType' in namespace 'llvm'
>>> >>   llvm::CompositeType *llct,
>>> >>   ~~^
>>> >> /home/jeremy/llvm-project/llvm/tools/gollvm/bridge/go-llvm.h:471:47:
>>> error: no type named 'CompositeType' in namespace 'llvm'
>>> >> llvm::CompositeType *llct,
>>> >> ~~^
>>> >> 2 errors generated.
>>> >> ninja: build stopped: subcommand failed.
>>> >
>>> >
>>> > It seems that the CompositeType exists in the
>>> mlir/include/mlir/Dialect/SPIRV/SPIRVTypes.h file, but I don't know if it
>>> is the same that the one needed here. Having never worked with ninja nor
>>> cmake before, I don't know what needs to be changed to include those files
>>> - if it is indeed the one we need.
>>> >
>>> > If you need any informations about my environment, feel free to ask me.
>>> >
>>> > --
>>> > You received this message because you are subscribed to the Google
>>> Groups "golang-nuts" group.
>>> > To unsubscribe from this group and stop receiving emails from it, send
>>> an email to golang-nuts+unsubscr...@googlegroups.com.
>>> > To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/a14de848-b677-4c17-84b3-b5d1ee5057c3%40googlegroups.com
>>> .
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BUr55Hqe1KkSNSakxBWxp0E5yx-kjZYyejjBPsNUEea%2Bi8T6Q%40mail.gmail.com.

Re: [go-nuts] [gollvm] Cannot build project : no type named 'CompositeType' in namespace 'llvm'

['Than McIntosh' via golang-nuts]

Hello again,

The gollvm sources were indeed out of date with LLVM tip. I sent

https://go-review.googlesource.com/c/gollvm/+/226637

to resolve the problem. I'll let you know when this is checked in.

Thanks, Than


On Tue, Mar 31, 2020 at 12:40 PM Than McIntosh  wrote:

> Hi,
>
> I'll take a look to see if I can reproduce the problem.
>
> Gollvm is "out of tree", meaning that when LLVM headers and data
> structures change things can get out of sync, but I'll need to confirm.
>
> Thanks, Than
>
>
>
> On Tue, Mar 31, 2020 at 12:16 PM Ian Lance Taylor  wrote:
>
>> [ + thanm, cherryyz ]
>>
>> On Tue, Mar 31, 2020 at 9:03 AM  wrote:
>> >
>> > Hi,
>> >
>> > I am currently trying to build the gollvm compiler.
>> > I have followed the instructions provided on the Google source page, up
>> until the "ninja gollvm" instruction, the only difference being that my
>> workarea folder is named build-gollvm. At this point, I get the following
>> error :
>> >
>> >> [1/1243] Building CXX object
>> tools/gol...pGoFrontEnd.dir/go-llvm-builtins.cpp.o
>> >> FAILED:
>> tools/gollvm/bridge/CMakeFiles/LLVMCppGoFrontEnd.dir/go-llvm-builtins.cpp.o
>> >> /usr/bin/c++  -DGTEST_HAS_RTTI=0 -D_DEBUG -D_GNU_SOURCE
>> -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
>> -Itools/gollvm/bridge -I/home/jeremy/llvm-project/llvm/tools/gollvm/bridge
>> -Iinclude -I/home/jeremy/llvm-project/llvm/include
>> -Itools/gollvm/external/install/include
>> -I/home/jeremy/llvm-project/llvm/tools/gollvm/gofrontend/go -fPIC
>> -fvisibility-inlines-hidden -Werror=date-time
>> -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter
>> -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic
>> -Wno-long-long -Wimplicit-fallthrough -Wcovered-switch-default
>> -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor
>> -Wno-comment -Wstring-conversion -fdiagnostics-color -g-fno-exceptions
>> -fno-rtti -std=c++14 -MD -MT
>> tools/gollvm/bridge/CMakeFiles/LLVMCppGoFrontEnd.dir/go-llvm-builtins.cpp.o
>> -MF
>> tools/gollvm/bridge/CMakeFiles/LLVMCppGoFrontEnd.dir/go-llvm-builtins.cpp.o.d
>> -o
>> tools/gollvm/bridge/CMakeFiles/LLVMCppGoFrontEnd.dir/go-llvm-builtins.cpp.o
>> -c /home/jeremy/llvm-project/llvm/tools/gollvm/bridge/go-llvm-builtins.cpp
>> >> In file included from
>> /home/jeremy/llvm-project/llvm/tools/gollvm/bridge/go-llvm-builtins.cpp:13:
>> >> /home/jeremy/llvm-project/llvm/tools/gollvm/bridge/go-llvm.h:463:45:
>> error: no type named 'CompositeType' in namespace 'llvm'
>> >>   llvm::CompositeType *llct,
>> >>   ~~^
>> >> /home/jeremy/llvm-project/llvm/tools/gollvm/bridge/go-llvm.h:471:47:
>> error: no type named 'CompositeType' in namespace 'llvm'
>> >> llvm::CompositeType *llct,
>> >> ~~^
>> >> 2 errors generated.
>> >> ninja: build stopped: subcommand failed.
>> >
>> >
>> > It seems that the CompositeType exists in the
>> mlir/include/mlir/Dialect/SPIRV/SPIRVTypes.h file, but I don't know if it
>> is the same that the one needed here. Having never worked with ninja nor
>> cmake before, I don't know what needs to be changed to include those files
>> - if it is indeed the one we need.
>> >
>> > If you need any informations about my environment, feel free to ask me.
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> Groups "golang-nuts" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> an email to golang-nuts+unsubscr...@googlegroups.com.
>> > To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/a14de848-b677-4c17-84b3-b5d1ee5057c3%40googlegroups.com
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BUr55E8ANm7YhkPde90PHj%2B3qoUTyCyEdftHBNdn6F53_nA%2Bw%40mail.gmail.com.

Re: [go-nuts] [gollvm] Cannot build project : no type named 'CompositeType' in namespace 'llvm'

['Than McIntosh' via golang-nuts]

Hi,

I'll take a look to see if I can reproduce the problem.

Gollvm is "out of tree", meaning that when LLVM headers and data structures
change things can get out of sync, but I'll need to confirm.

Thanks, Than



On Tue, Mar 31, 2020 at 12:16 PM Ian Lance Taylor  wrote:

> [ + thanm, cherryyz ]
>
> On Tue, Mar 31, 2020 at 9:03 AM  wrote:
> >
> > Hi,
> >
> > I am currently trying to build the gollvm compiler.
> > I have followed the instructions provided on the Google source page, up
> until the "ninja gollvm" instruction, the only difference being that my
> workarea folder is named build-gollvm. At this point, I get the following
> error :
> >
> >> [1/1243] Building CXX object
> tools/gol...pGoFrontEnd.dir/go-llvm-builtins.cpp.o
> >> FAILED:
> tools/gollvm/bridge/CMakeFiles/LLVMCppGoFrontEnd.dir/go-llvm-builtins.cpp.o
> >> /usr/bin/c++  -DGTEST_HAS_RTTI=0 -D_DEBUG -D_GNU_SOURCE
> -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
> -Itools/gollvm/bridge -I/home/jeremy/llvm-project/llvm/tools/gollvm/bridge
> -Iinclude -I/home/jeremy/llvm-project/llvm/include
> -Itools/gollvm/external/install/include
> -I/home/jeremy/llvm-project/llvm/tools/gollvm/gofrontend/go -fPIC
> -fvisibility-inlines-hidden -Werror=date-time
> -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter
> -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic
> -Wno-long-long -Wimplicit-fallthrough -Wcovered-switch-default
> -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor
> -Wno-comment -Wstring-conversion -fdiagnostics-color -g-fno-exceptions
> -fno-rtti -std=c++14 -MD -MT
> tools/gollvm/bridge/CMakeFiles/LLVMCppGoFrontEnd.dir/go-llvm-builtins.cpp.o
> -MF
> tools/gollvm/bridge/CMakeFiles/LLVMCppGoFrontEnd.dir/go-llvm-builtins.cpp.o.d
> -o
> tools/gollvm/bridge/CMakeFiles/LLVMCppGoFrontEnd.dir/go-llvm-builtins.cpp.o
> -c /home/jeremy/llvm-project/llvm/tools/gollvm/bridge/go-llvm-builtins.cpp
> >> In file included from
> /home/jeremy/llvm-project/llvm/tools/gollvm/bridge/go-llvm-builtins.cpp:13:
> >> /home/jeremy/llvm-project/llvm/tools/gollvm/bridge/go-llvm.h:463:45:
> error: no type named 'CompositeType' in namespace 'llvm'
> >>   llvm::CompositeType *llct,
> >>   ~~^
> >> /home/jeremy/llvm-project/llvm/tools/gollvm/bridge/go-llvm.h:471:47:
> error: no type named 'CompositeType' in namespace 'llvm'
> >> llvm::CompositeType *llct,
> >> ~~^
> >> 2 errors generated.
> >> ninja: build stopped: subcommand failed.
> >
> >
> > It seems that the CompositeType exists in the
> mlir/include/mlir/Dialect/SPIRV/SPIRVTypes.h file, but I don't know if it
> is the same that the one needed here. Having never worked with ninja nor
> cmake before, I don't know what needs to be changed to include those files
> - if it is indeed the one we need.
> >
> > If you need any informations about my environment, feel free to ask me.
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "golang-nuts" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to golang-nuts+unsubscr...@googlegroups.com.
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/a14de848-b677-4c17-84b3-b5d1ee5057c3%40googlegroups.com
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BUr55E%3DsbcaMT5shkLDC%2Boh-X9yfYZBO%3DRd4V%2BQ-fOAB0igfw%40mail.gmail.com.

Re: [go-nuts] gollvm: Interpret llvm-goc LLVM-IR with lli

['Than McIntosh' via golang-nuts]

>>in this case is Only GOLLVM does not allow to go direct to .ll or it is
general issue

It's a general issue. Hypothetically if someone were to write another
LLVM-IR-producing Go compiler (not gollvm), you would no doubt have the
same problem.

Than


On Tue, Feb 4, 2020 at 9:55 AM  wrote:

> in this case is Only GOLLVM does not allow to go direct to .ll or it is
> general issue. on the other hand, Is any way or tools that
> compile/interpret/convert from GO to .LL
>
> best wishes
>
>
> On Tuesday, February 4, 2020 at 8:59:14 AM UTC-5, Than McIntosh wrote:
>>
>> Hello,
>>
>> You wrote:
>> >> .. . result that I get can not exec the .ll file by lli command
>>
>> Go programs depend on the Go runtime and standard library -- you can't
>> really do anything interesting in Go without involving these packages.
>>
>> Consider a toy program like this: https://play.golang.org/p/MAohLsrz7JQ
>>
>> When this Go program runs, the Go runtime does a lot of setup work
>> (initializing the scheduler, the garbage collector, etc) before main.main
>> is ever invoked. Then when main.main calls fmt.Println(), there is (again)
>> a lot of runtime involvement needed to carry out the work of printing a
>> message.
>>
>> When you run "lli" on just a single bitcode file generated from compiling
>> a Go main package with llvm-goc, "lli" can't really do much with it since
>> you aren't also handing off a copy of the go runtime.
>>
>> Folks have experimented in the past with hacking up the compiler and
>> runtime to get it into a form where it will work with lli, but this is not
>> a supported usage mode for Gollvm at the moment (a good deal more
>> engineering work would be needed, due to the oddities of how "lli" works).
>>
>> Thanks, Than
>>
>>
>> On Tue, Feb 4, 2020 at 8:21 AM  wrote:
>>
>>> Hello!
>>> I am doing a project in which I need to generate LLVM IR file by use
>>> gollvm . but the result that I get can not exec the .ll file by lli command
>>> any suggestion
>>> best wishes
>>>
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to golan...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/7bbfcb8f-f488-445d-bd78-0c531cd42b1d%40googlegroups.com
>>> 
>>> .
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/f485eb0d-75fd-4578-837a-3bd766d22d70%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BUr55G8ewOtjmcUWBFz8vk5K_2h7Cp3Laii-TCgB5kkxHxOnQ%40mail.gmail.com.

Re: [go-nuts] gollvm: Interpret llvm-goc LLVM-IR with lli

['Than McIntosh' via golang-nuts]

Hello,

You wrote:
>> .. . result that I get can not exec the .ll file by lli command

Go programs depend on the Go runtime and standard library -- you can't
really do anything interesting in Go without involving these packages.

Consider a toy program like this: https://play.golang.org/p/MAohLsrz7JQ

When this Go program runs, the Go runtime does a lot of setup work
(initializing the scheduler, the garbage collector, etc) before main.main
is ever invoked. Then when main.main calls fmt.Println(), there is (again)
a lot of runtime involvement needed to carry out the work of printing a
message.

When you run "lli" on just a single bitcode file generated from compiling a
Go main package with llvm-goc, "lli" can't really do much with it since you
aren't also handing off a copy of the go runtime.

Folks have experimented in the past with hacking up the compiler and
runtime to get it into a form where it will work with lli, but this is not
a supported usage mode for Gollvm at the moment (a good deal more
engineering work would be needed, due to the oddities of how "lli" works).

Thanks, Than


On Tue, Feb 4, 2020 at 8:21 AM  wrote:

> Hello!
> I am doing a project in which I need to generate LLVM IR file by use
> gollvm . but the result that I get can not exec the .ll file by lli command
> any suggestion
> best wishes
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/7bbfcb8f-f488-445d-bd78-0c531cd42b1d%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BUr55Fr3bsDtCOw_YNsuWSo3g5x5%2Bf89FKPZ9HqQ3bcrNBtUw%40mail.gmail.com.

Re: [go-nuts] [gollvm] Can't exec LLVM IR from go code

['Than McIntosh' via golang-nuts]

Greetings,

What you are seeing is expected behavior. In your "hello.go" file, you've
defined a "main.main" function, however in order to run that function you
need a copy of the Go runtime and standard libraries. When a Go program
runs, the "main" function is in fact part of the runtime -- the runtime
does a lot of initialization work to set up the scheduler, garbage
collector, etc before eventually getting around to invoking the
user-written main.main function.

The interpreter has a number of other quirks and restrictions that make it
tricky to use for running Go programs -- folks have experimented with using
it in the past (see https://go-review.googlesource.com/c/gofrontend/+/140917)
but it is not something that is supported directly out of the box.

Hope this helps.

Than

On Fri, Nov 29, 2019 at 11:24 AM  wrote:

> Hello! I recently want to use gollvm to analyse code. However I met a
> problem after I get the llvm ir whith the instructions shown in gollvm
> official doc * I can not exec the .ll file by lli command*
>
> 
> zty@zty-server:~/go-projects/src/testfile$ cat hello.go
> package main
>
> import "fmt"
>
> func main() {
> fmt.Println("hello world!")
> return
> }
>
> zty@zty-server:~/go-projects/src/testfile$ go build -work -x hello.go 1>
> transcript_hello.txt 2>&1
>
> zty@zty-server:~/go-projects/src/testfile$ egrep '(WORK=|llvm-goc -c)'
> transcript_hello.txt
> WORK=/tmp/go-build177380678
> /usr/local/llvmgo/bin/llvm-goc -c -O2 -g -m64
> -fdebug-prefix-map=$WORK=/tmp/go-build -gno-record-gcc-switches
> -fgo-relative-import-path=_/home/zty/go-projects/src/testfile -o
> $WORK/b001/_go_.o -I $WORK/b001/_importcfgroot_ ./hello.go
> $WORK/b001/_gomod_.go
>
> zty@zty-server:~/go-projects/src/testfile$ /usr/local/llvmgo/bin/llvm-goc
> -c -O2 -g -m64 -fdebug-prefix-map=/tmp/go-build177380678=/tmp/go-build
> -gno-record-gcc-switches
> -fgo-relative-import-path=_/home/zty/go-projects/src/testfile -o hello.ll
> -S -emit-llvm -I /tmp/go-build177380678/b001/_importcfgroot_ ./hello.go
> /tmp/go-build177380678/b001/_gomod_.go
>
> zty@zty-server:~/go-projects/src/testfile$ ls hello.ll
> hello.ll
>
> zty@zty-server:~/go-projects/src/testfile$ lli hello.ll
> lli: error: 'main' function not found in module.
> ---
>
> After I get the hello.ll, I can *not exec it by lli* command, while for *other
> .ll from c code I can exec it*.
> And I find that *llvm pass can work on this "hello.ll"*, so what's the
> reason of it?
>
> -  Hello World pass work as normal
>
> zty@zty-server:~/go-projects/src/testfile$ opt -load
> /home/zty/workarea/llvm-project/build/lib/LLVMHello.so -hello -time-passes
> < hello.ll > /dev/null
> Hello: __go_init_main
> Hello: main.main
> Hello: main.main..init0
> Hello: main.struct.4runtime.gList.2.runtime.n.0int32.5..hash
> Hello: main.struct.4runtime.gList.2.runtime.n.0int32.5..eq
> Hello: main.struct.4Size.0uint32.2Mallocs.0uint64.2Frees.0uint64.5..hash
> Hello: main.struct.4Size.0uint32.2Mallocs.0uint64.2Frees.0uint64.5..eq
>
> ===-===
>   ... Pass execution timing report ...
>
> ===-===
>   Total Execution Time: 0.0022 seconds (0.0022 wall clock)
>
>---User Time---   --User+System--   ---Wall Time---  --- Name ---
>0.0017 ( 77.3%)   0.0017 ( 77.3%)   0.0017 ( 77.4%)  Bitcode Writer
>0.0004 ( 18.2%)   0.0004 ( 18.2%)   0.0004 ( 18.1%)  Hello World Pass
>0.0001 (  4.4%)   0.0001 (  4.4%)   0.0001 (  4.5%)  Module Verifier
>0.0022 (100.0%)   0.0022 (100.0%)   0.0022 (100.0%)  Total
>
>
> ===-===
> LLVM IR Parsing
>
> ===-===
>   Total Execution Time: 0.0023 seconds (0.0023 wall clock)
>
>---User Time---   --User+System--   ---Wall Time---  --- Name ---
>0.0023 (100.0%)   0.0023 (100.0%)   0.0023 (100.0%)  Parse IR
>0.0023 (100.0%)   0.0023 (100.0%)   0.0023 (100.0%)  Total
>
> 
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/bf03fa0d-d119-4faa-93c8-441b46d5634d%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving 

Re: [go-nuts] How to build gollvm on arm platform

['Than McIntosh' via golang-nuts]

Hi Eric,

Yes, this is a problem that is pretty much guaranteed to happen given the
way the C ABI works in LLVM.  All of the test results
in BackendCABIOracleTests.cpp are specific to the details of the amd64 ABI.

The way that I had imagined this working was that either each testpoint has
a loop over the various supported ABI flavors (and checks output for each
flavor), or we have separate testpoints for each ABI
(e.g. TEST(BackendCABIOracleTests, X8664_RecursiveCall1) or equivalent. Or
even separate test files, depending on what's more convenient. It would be
nice if FcnTestHarness could be extended to accept a "target ABI"
parameter, maybe? Whatever you think is the best approach.

Thanks for taking care of this --

Than




On Fri, Oct 25, 2019 at 2:41 AM eric fang  wrote:

> Hi Than,
>
> I'm porting the unit test cases of x86 to arm64. As the difference between
> x86 abi and arm64 abi, for the same go code snippet, the generated llvm IRs
> maybe different.
> How do you get the correct IR result of a unit test? Such as unit
> test TEST(BackendCABIOracleTests, RecursiveCall1). Is there any quick way?
>
> Thanks.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/bcd0ea2c-d1e3-43f7-88ea-0c8de78f96f6%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BUr55FciscRp%2BYPLo_PVBXQx1pF%2BMZdBrY3WT_U8%2B56-Sb13Q%40mail.gmail.com.

Re: [go-nuts] pprof not showing call hierarchy for time.now and time.Until

['Than McIntosh' via golang-nuts]

The "tree" output format is modeled approximately after the output of the
ancient unix tool "gprof" (see
https://ftp.gnu.org/old-gnu/Manuals/gprof-2.9.1/html_chapter/gprof_5.html).

For tree output, you'll see entries of the form

Caller(s)
  Function
Callee(s)

where "flat" shows the time spent in "Function" itself (as opposed to in
things that "Function" calls) and "cum" shows total time spent inside the
function (e.g. includes callees).

If you have a leaf function, then you would expect that "flat" == "cum". If
you have a function that does very little but calls something that takes a
long time, then you would expect that "flat" is small but "cum" is large.

With that, the fragment of the tree profile you sent seems pretty weird.
The time.now function calls walltime and nanotime, both of which invoke
VDSO functions on linux -- from the perspective of a non-expert in Go
runtime stuff, I am not sure why there would be a lot of time attributed to
time.now itself and not the functions it calls (stack switching, maybe?).

Than


On Mon, Oct 21, 2019 at 7:19 AM Piers Powlesland 
wrote:

> Hi Than,
>
> Thanks for the tip.
>
> I actually discovered that selecting a node and using the Focus option
> from the Refine in
> the web view gets me a clear view of the callers and callees for the
> selected node.
>
> I have tried the tree view, passing the focus option on the command line
> but I' don't understand
> how to read it.
>
> Here is a snippet from the top of the output for tree
>
> Showing nodes accounting for 20.68s, 15.59% of 132.61s total
> --+-
>   flat  flat%   sum%cum   cum%   calls calls% + context
> --+-
>  0.04s  0.19% |   time.Now
> 20.65s 15.57% 15.57% 20.68s 15.59%| time.now
>  0.03s  0.15% |
> runtime.nanotime
> --+-
>  0.03s   100% |   time.now
>  0.03s 0.023% 15.59%  0.03s 0.023%|
> runtime.nanotime
> --+-
>  0.02s   100% |
> github.com/piersy/new_project/worker.NewWorker.func1
>  0 0% 15.59%  0.02s 0.015%|
> github.com/piersy/new_project/network.(*Connection).Read
>  0.02s   100% |
> github.com/piersy/new_project/network.(*Connection).read
> --+-
>  0.01s   100% |
> github.com/piersy/new_project/worker.(*Listener).listen.func1
>  0 0% 15.59%  0.01s 0.0075%|
> github.com/piersy/new_project/network.(*Connection).Write
>  0.01s   100% |
> github.com/piersy/new_project/network.(*Connection).write
> --+-
>  0.02s   100% |
> github.com/piersy/new_project/network.(*Connection).Read
>  0 0% 15.59%  0.02s 0.015%|
> github.com/piersy/new_project/network.(*Connection).read
>  0.02s   100% |   time.Now
> --+-
>  0.01s   100% |
> github.com/piersy/new_project/network.(*Connection).Write
>  0 0% 15.59%  0.01s 0.0075%|
> github.com/piersy/new_project/network.(*Connection).write
>  0.01s   100% |   time.Now
> --+-
>
> In the web view when focused on time.now I can see the lower entries
> entries appearing in the call
> hierarchy leading to time.now, but here in the tree view they appear
> disconnected, the only hint that
> these entries call time.now is that I used the focus flag to focus on
> time.now.
>
> In the case that I haven't used the focus flag, I'm wondering how  I would
> be able to relate entries in
> the tree to one another?
>
> I also tried using the peek flag, which if set to time.now, only prints
> the first
> entry from the tree output above.
>
>
> On Mon, Oct 21, 2019 at 8:10 AM Than McIntosh  wrote:
>
>> It can sometimes be useful in such situations to look at the pprof "tree"
>> output style (as opposed to graph).
>>
>> Than
>>
>>
>> On Sat, Oct 19, 2019 at 4:14 AM Piers Powlesland <
>> pierspowlesl...@gmail.com> wrote:
>>
>>> Kind of, but due to the sheer number of nodes and edged the edges end up
>>> lying on top of each other so in 

Re: [go-nuts] pprof not showing call hierarchy for time.now and time.Until

['Than McIntosh' via golang-nuts]

It can sometimes be useful in such situations to look at the pprof "tree"
output style (as opposed to graph).

Than


On Sat, Oct 19, 2019 at 4:14 AM Piers Powlesland 
wrote:

> Kind of, but due to the sheer number of nodes and edged the edges end up
> lying on top of each other so in certain cases you end up having to check
> the source of several nodes to see which is the caller.
>
> On Sat, 19 Oct 2019, 03:08 Robert Engels,  wrote:
>
>> But also can’t you just find that node in the graph and see the callers?
>>
>> On Oct 18, 2019, at 8:54 PM, Robert Engels  wrote:
>>
>> 
>> Yes. When using the command pprof viewer there is a way to show the
>> hotspots with the callers. Again I don’t have access to dev at the moment.
>>
>> On Oct 18, 2019, at 8:44 PM, Piers Powlesland 
>> wrote:
>>
>> 
>> Hi Robert,
>>
>> I think I found the options you were referring to, and I was able to get
>> the whole overview with the following.
>>
>> go tool pprof -http : -edgefraction 0 -nodefraction 0 -nodecount
>> 10 cpu.prof
>>
>> Its a bit of a screenfull though, and I was wondering if there is any
>> simpler way to find out who is calling what?
>> So that I could dig down through top and if the function isn't in my code
>> follow the callstack to find what part of my code
>> initiated the call.
>>
>> On Fri, Oct 18, 2019 at 8:52 PM Robert Engels 
>> wrote:
>>
>>> I am pretty sure there is a way to filter nodes that are less than X %,
>>> and some of that filtering is on by default - so you may want to turn that
>>> off (can't say for sure since not at dev machine right now).
>>>
>>>
>>>
>>>
>>>
>>> -Original Message-
>>> >From: Ian Lance Taylor 
>>> >Sent: Oct 18, 2019 2:43 PM
>>> >To: Piers Powlesland 
>>> >Cc: golang-nuts 
>>> >Subject: Re: [go-nuts] pprof not showing call hierarchy for time.now
>>> and time.Until
>>> >
>>> >On Fri, Oct 18, 2019 at 12:37 PM  wrote:
>>> >>
>>> >> I used pprof to get an overview of where time is being spent in my
>>> latest project and I'm
>>> >> getting a result I don't understand. When using the web view, there
>>> are certain function
>>> >> calls that are taking up a large percentage of the time but they
>>> appear un-rooted as in
>>> >> there seems to be no parent call calling them.
>>> >>
>>> >> I have attached a picture of the web view showing just the un-rooted
>>> functions.
>>> >>
>>> >> I generated the profile with the following command.
>>> >>
>>> >> go test -cpuprofile cpu.prof -count 4 . -run MyTest
>>> >>
>>> >> and I viewed the profile with the following command.
>>> >>
>>> >> go tool pprof -http : cpu.prof
>>> >>
>>> >> I'd really like to track down what is causing all this time in the
>>> time package, but I'm
>>> >> at a bit of a loss.
>>> >
>>> >Which version of Go and which GOOS/GOARCH?  There have been bugs in
>>> >this area in the past, and at least some of them are fixed in 1.13.
>>> >
>>> >Ian
>>> >
>>> >--
>>> >You received this message because you are subscribed to the Google
>>> Groups "golang-nuts" group.
>>> >To unsubscribe from this group and stop receiving emails from it, send
>>> an email to golang-nuts+unsubscr...@googlegroups.com.
>>> >To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/CAOyqgcWReW9e79szp29F11nmvVEzhZr7O%3D1Qp5WXkGBLwWprBA%40mail.gmail.com
>>> .
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/876AA5BF-E048-4A7D-8842-9E40B3F9FA26%40ix.netcom.com
>> 
>> .
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAFXacX%3DJrvC8VqUs%2BCQr0SOBgfH4vtO5fyrYGVFidduH067OrA%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BUr55F%2Bn%2BqJzLACB1jY9x9xAdDThDyq6gfpSDs%2BRa1f%3DEgq8A%40mail.gmail.com.

Re: [go-nuts] How to build gollvm on arm platform

['Than McIntosh' via golang-nuts]

Thanks for the update. BlockLIRBuilder sounds like the right way to go, and
your plan to add unit tests SGTM.

Agree that we'll need to thread through the arch/callingConv into the unit
testing framework, let me know if I can help with that.

Cheers, Than





On Wed, Sep 18, 2019 at 3:46 AM eric fang  wrote:

> Hi Than, I think here should be the right place to handle this case, and I
> have corrected the code. I should use BlockLIRBuilder instead of
> BinstructionLIRBuilder. I have implemented a prototype of the code and at
> present everything is normal. Next I will start writing some unit test
> cases. There are some places that are not easy to extend. For example, in
> the constructor of class Llvm_backend, calling convention is hard coded,
> and the unit test needs to get an Llvm_backend instance through the
> go_get_backend function in the file bridge/go-llvm.cpp. I am thinking about
> how to deal with this.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/4283a098-d922-4a52-ae61-cd3c8d1880b1%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BUr55EPBy70%2BkLVz%2B12r-SQO6Ap22xZd5ZgSBTjn9MJCiHvFg%40mail.gmail.com.

Re: [go-nuts] How to build gollvm on arm platform

['Than McIntosh' via golang-nuts]

Sent https://go-review.googlesource.com/c/gollvm/+/190900 to improve
comments.
Thanks, Than


On Tue, Aug 20, 2019 at 9:33 AM Than McIntosh  wrote:

> Hi Eric,
>
> Thanks for the note. Your question about the code in
> CABIOracle::canPassDirectly, e.g .
>
>   if (regsInt + regsSSE == 1)
> return true;
>
> is a good one.  I'll see about adding some comments to the code there.
>
> By way of explanation, the Gollvm code is modeled after the approach used
> in clang, which does something similar in this case. For example, consider
> the following small C program:
>
> typedef unsigned long long u;
> extern u bar(u p1, u p2, u p3, u p4, u p5, u p6, u p7, u p8, u p9, u p10);
> u foo(u p) {
>   return bar(1,2,3,4,5,6,7,8,9,p);
> }
>
> Let's say you compile this code with clang for x86_64 and look at the
> emitted LLVM IR and emitted assembly, e.g.
>
> clang -c -S file.c -O
> clang -c -S file.c -O -emit-llvm
>
> In the *.ll file you'll see this LLVM IR for 'foo':
>
> define i64 @foo(i64) local_unnamed_addr #0 {
>   %2 = tail call i64 @bar(i64 1, i64 2, i64 3, i64 4, i64 5, i64 6, i64
> %0) #2
>   ret i64 %2
> }
>
> What is interesting here is that the function being called, "bar", has 7
> arguments. Under the rules of the C/C++ ABI for x86_64, not all of the
> parameters can be passed in registers -- some of them have to go in memory.
> However looking at the signature, there are no memory arguments, everything
> is being passed by value. Now let's look at the assembly:
>
> foo:
> pushq %rax
> *movq %rdi, (%rsp)*
> movl $1, %edi
> movl $2, %esi
> movl $3, %edx
> movl $4, %ecx
> movl $5, %r8d
> movl $6, %r9d
> callq bar
> popq %rcx
> retq
>
>
> As you can see, the back end knows about the rules of the C/C++ ABI for
> x86_64, and it has put the right things in registers and in memory so that
> the ABI is honored.
>
> So essentially what's happening is that the front end (clang) is playing a
> little game with the back end -- for the more complicated cases involving
> aggregates and things bigger than a single register, the front end makes
> the LLVM IR explicit with regard to what gets passed in memory via by
> value. For small parameters (things that will fit into a single register)
> it just leaves them by value and counts on having the back end sort it out.
> Doing things this way has advantages from a performance perspective.
>
> For your second question, yes, your approach seems reasonable --
> making CABIOracle into a base class and then adding virtual methods seems
> like the right way to go. I don't have any very specific advice on classes
> like CABIParamInfo and EightByteInfo -- I would say the former seems a bit
> more abstract and reusable whereas the notion of an "EightByte" seems
> pretty specific to the language in the x86_64 abi description. I would just
> take your best shot and see how things go.
>
> Hope this helps, let me know if you have other questions...
>
> Thanks, Than
>
>
>
>
> On Tue, Aug 20, 2019 at 8:42 AM eric fang  wrote:
>
>> Hi Than,
>>
>> I'm trying to implement the abi part for arm64, and got two questions for
>> you:
>>
>> 1, function CABIOracle::canPassDirectly in
>> gollvm/bridge/go-llvm-cabi-oracle.cpp, I'm not quite understand the first
>> if statement:
>>   if (regsInt + regsSSE == 1)
>>return true;
>>   Why not consider whether there are enough available registers here?
>>
>> 2, I plan to abstract the CABIOracle class into a base class, and each
>> architecture implements an inheritance class based on this class. But there
>> are some auxiliary classes and structures (like class CABIParamInfo and
>> EightByteInfo etc.) in this file that are also x86 specific. I haven't
>> figured out how to handle these yet, maybe some of them are also reusable.
>> Do you think this design is reasonable? Any suggestions? I should submit a
>> prototype patch, which would be more convenient to discuss, but I have not
>> implemented it yet. . .
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/702e3129-b72a-411d-80fe-70e9daae207d%40googlegroups.com
>> 
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BUr55H-iUvayr4iREbK%2BgqWs%2Bt9h1fBNSpqzMujSnLke7VpNw%40mail.gmail.com.