Re: [go-nuts] Re: `ltrace` yields "Couldn't find .dynsym or .dynstr in "/proc/*/exe" with binaries generated by "go build *.go"

What is the problem you are trying to solve? Said another way. If you can confirm (or disprove, whichever suits) that Go uses __vdso_clock_gettime_sym with CLOCK_MONOTONIC, what would you do with that information? On Monday, 18 September 2017 09:08:41 UTC+10, Ronald wrote: > > In `go1.9 @

Re: [go-nuts] Re: `ltrace` yields "Couldn't find .dynsym or .dynstr in "/proc/*/exe" with binaries generated by "go build *.go"

Which in this case, the `strace` cannot trace a single syscall that involves the time. On Mon, Sep 18, 2017 at 7:08 AM, Sen Han wrote: > In `go1.9 @ linux 3.10.0-327.el7.x86_64`, the call __vdso_clock_gettime_sym > is > completely in userspace, and does not involve any

Re: [go-nuts] Re: `ltrace` yields "Couldn't find .dynsym or .dynstr in "/proc/*/exe" with binaries generated by "go build *.go"

In `go1.9 @ linux 3.10.0-327.el7.x86_64`, the call __vdso_clock_gettime_sym is completely in userspace, and does not involve any syscall in the kernel, and that is the reason __vdso_clock_gettime_sym with CLOCK_MONOTONIC is so fast. ( In C, the perf of __vdso_clock_gettime_sym is about 14,000,000

[go-nuts] Re: `ltrace` yields "Couldn't find .dynsym or .dynstr in "/proc/*/exe" with binaries generated by "go build *.go"

You may need to look and see what __vdso_clock_gettime_sym calls at the system-call level, and compare that with the system calls reported by strace from your executable. I assume you want some particular thing that __vdso_clock_gettime_sym does: try asking the folks about *that*, as they may