Getting a function's linked address?

187 views
Skip to first unread message

julio....@gmail.com

unread,
Oct 29, 2019, 1:54:19 PM10/29/19
to golang-nuts
Hello,

I am wondering if it is possible to get the address of a function but at link-time. Kind of the equivalent to the C keyword `extern`.

Maybe using the link name directive? But it is not super clear to me.

I would like to get them instead at link time instead of using the gosymtab.

Thank you

Ian Lance Taylor

unread,
Oct 29, 2019, 7:00:55 PM10/29/19
to julio....@gmail.com, golang-nuts
That's not what the C keyword "extern" does, so I'm not sure quite
what you mean.

What do you want to do with the address?

You can get *an* address of the function f by writing
reflect.Value(f).Pointer(), but I don't know if that is the address
that you want.

Ian

julio....@gmail.com

unread,
Oct 30, 2019, 2:45:38 AM10/30/19
to golang-nuts
I was meaning an equivalent to declaring an extern function using the same name as the symbol we want. The function address will be the linked symbol address.

I indeed use the reflect package today, but this happen at run time while I would like to get those values at link time. I'd like to create a lookup table to function addresses.

Ian Lance Taylor

unread,
Oct 30, 2019, 11:01:50 AM10/30/19
to julio....@gmail.com, golang-nuts
On Tue, Oct 29, 2019 at 11:45 PM <julio....@gmail.com> wrote:
>
> I was meaning an equivalent to declaring an extern function using the same name as the symbol we want. The function address will be the linked symbol address.
>
> I indeed use the reflect package today, but this happen at run time while I would like to get those values at link time. I'd like to create a lookup table to function addresses.

You can create a lookup table at run time. What would change if you
could do it at link time? Can you show us the code you want to write?

Ian

julio....@gmail.com

unread,
Oct 31, 2019, 5:58:12 PM10/31/19
to golang-nuts
You can create a lookup table at run time.  What would change if you
could do it at link time?  Can you show us the code you want to write?

This is actually linked to my remark on build-time source instrumentation on https://github.com/golang/go/issues/35204 : I insert hooks into functions and then use a lookup table to find them at run time. Currently, they are created using a function which adds the newly created pointer into a global map, thus done at "Go init time". But if we say that I shouldn't add new dependencies when from a -toolexec tool, I need to create this same lookup table differently.

TBH, I just would like to know if getting a symbol address at link time is possible. Because I actually found today a workaround to be able to add new dependencies my -toolexec tool. But I may need to do this later on.

The other idea I had in mind was using the gosymtab to find function adresses but it looks like this section is not always present and I am not sure how long it will be supported.

Ian Lance Taylor

unread,
Oct 31, 2019, 6:57:08 PM10/31/19
to julio....@gmail.com, golang-nuts
On Thu, Oct 31, 2019 at 2:58 PM <julio....@gmail.com> wrote:
>
> TBH, I just would like to know if getting a symbol address at link time is possible. Because I actually found today a workaround to be able to add new dependencies my -toolexec tool. But I may need to do this later on.

I'm still not 100% clear on what this means but I'm fairly sure that
the answer is no for any meaning.

> The other idea I had in mind was using the gosymtab to find function adresses but it looks like this section is not always present and I am not sure how long it will be supported.

The gosymtab may or may not be there, but the executable's symbol
table will normally be there.

Ian

Julio Guerra

unread,
Jan 15, 2020, 4:47:09 AM1/15/20
to golang-nuts
For the record, I could do what I needed using the `//go:linkname` directive.

My instrumentation tool injects statements that need features from another package that I cannot import. So I forward declare functions using a given link name that is implemented in another package - similarly to what can be found in the stdlib.

This way, the forward declarations get resolved at link time - similarly to what you can do with `extern` with GCC.
Reply all
Reply to author
Forward
0 new messages