Mh, this is interesting. When I build a test binary with buildmode=pie, I even 
get an ELF section called `.data.rel.ro.gopclntab`. 

However, in the containerd binary, this section does not exist.There also is no 
`.gosymtab` section, as that is easily wiped by the `ldflags`. 

>  It is getting folded into the
> .data.rel.ro <http://data.rel.ro/> section.  You can still find the 
> information by looking
> at the symbol table: the .gopclntab data is between runtime.pclntab
> and runtime.epclntab.

I'm not sure I follow. 
If I understand correctly, this means that what I see in my test binary as 
`.data.rel.ro <http://data.rel.ro/>.gopclntab` is a subsection "within" the 
`.data.rel.ro <http://data.rel.ro/>` section.
Further, as the containerd binary has a `.data.rel.ro <http://data.rel.ro/>` 
section, at some offset within that data there should be a PCLN table? 

If so, two questions arise:
- How do I find that offset? By looking for the magic string for the PCLN 
table? 
- Why is that subsection not listed / present in the containerd binary? 

Thanks a lot, this is a very interesting topic! 
 
Ramon

PS: If you have some literature / documents on the Go specifics for this, I'd 
be curious to read them.

> On 18 Sep 2022, at 04:51, Ian Lance Taylor <i...@golang.org> wrote:
> 
> On Sat, Sep 17, 2022 at 2:48 PM 'Ramon Rüttimann' via golang-nuts
> <golang-nuts@googlegroups.com <mailto:golang-nuts@googlegroups.com>> wrote:
>> 
>> Sadly this does not seem to be the case, for example the nightly artifacts 
>> from containerd, which can be found here.
>> A `go version -m <binary>`  lists all deps & shows the Go version 1.19.1, 
>> but there is now PCLN table to be found...
>> The binary seems to be created through the following go build command:
>> 
>> go build -gcflags=-trimpath=/home/runner/work/containerd/containerd/src 
>> -buildmode=pie -o bin/containerd -ldflags '-X 
>> github.com/containerd/containerd/version.Version=290ef2b 
>> <http://github.com/containerd/containerd/version.Version=290ef2b> -X 
>> github.com/containerd/containerd/version.Revision=290ef2b43ff1b824e56d0adaebf621e053de6e86
>>  
>> <http://github.com/containerd/containerd/version.Revision=290ef2b43ff1b824e56d0adaebf621e053de6e86>
>>  -X 
>> github.com/containerd/containerd/version.Package=github.com/containerd/containerd
>>  
>> <http://github.com/containerd/containerd/version.Package=github.com/containerd/containerd>
>>  -s -w ' -tags "urfave_cli_no_docs" ./cmd/containerd
>> 
>> Local testing confirms that with `-buildmode=pie` ("Position Independent 
>> Executable") the PCLN table is not being added to the binary. Why?
>> I'm not familiar with these executables, not sure how this would affect the 
>> PCLN.
> 
> Interesting.  I agree: with -buildmode=pie the .gopclntab section does
> not appear in the final executable.  It is getting folded into the
> .data.rel.ro <http://data.rel.ro/> section.  You can still find the 
> information by looking
> at the symbol table: the .gopclntab data is between runtime.pclntab
> and runtime.epclntab.
> 
> Ian
> 
> 
>> On Friday, September 16, 2022 at 9:36:53 PM UTC+2 Ian Lance Taylor wrote:
>>> 
>>> On Fri, Sep 16, 2022 at 12:13 PM Ramon Rüttimann
>>> <ramon.ru...@gmail.com> wrote:
>>>> 
>>>> I am currently looking into what a built Go binary may contain and have 
>>>> found some confusing things around the `.gopclntab` ELF section, also 
>>>> known as the PCLN table.
>>>> 
>>>> At first, I assumed that the PCLN table is present in all binaries, no 
>>>> matter how they are built. I've done some tests with stripped, trimmed and 
>>>> CGo binaries and have found it to be present.
>>>> However, this article contains an interesting statement:
>>>> 
>>>> For ordinary unstripped Go binaries, this debugging information is in the 
>>>> .gopclntab and .gosymtab ELF sections of the binary, and can be read out 
>>>> with debug/elf/File.Section() and Section.Data(). Unfortunately, Go 
>>>> binaries that use cgo do not have these Go ELF sections. As mentioned in 
>>>> Building a better Go linker:
>>>> 
>>>> For “cgo” binaries, which may make arbitrary use of C libraries, the Go 
>>>> linker links all of the Go code into a single native object file and then 
>>>> invokes the system linker to produce the final binary.
>>>> 
>>>> This linkage obliterates .gopclntab and .gosymtab as separate ELF 
>>>> sections. I believe that their data is still there in the final binary, 
>>>> but I don't know how to extract them.
>>>> 
>>>> I have also found such binaries in the wild, like the `containerd` binary 
>>>> or some tools from Docker as well. I've tried to decipher how the 
>>>> containerd binary is being built (based on this Makefile), but I am not 
>>>> really familiar enough with Make to decipher this.
>>>> 
>>>> This S/O post has asked the same question, but the answer doesn't match 
>>>> what I've seen and also what that article claims.
>>>> 
>>>> Can someone shed some lights on how one can build CGo binaries without the 
>>>> `.pclntab` section? Also, what happens to stacktraces in such a case?
>>> 
>>> I believe that at least as of Go 1.19 the .gopclntab section exists
>>> even if the binary is built with cgo, and the .gosymtab section is
>>> empty in any case.
>>> 
>>> 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 
>> <mailto:golang-nuts+unsubscr...@googlegroups.com>.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/a831b72f-6ecd-41e4-a5fd-e76b4b9fc7fbn%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/a831b72f-6ecd-41e4-a5fd-e76b4b9fc7fbn%40googlegroups.com>.
> 
> -- 
> You received this message because you are subscribed to a topic in the Google 
> Groups "golang-nuts" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/golang-nuts/oxseUnhRtXM/unsubscribe 
> <https://groups.google.com/d/topic/golang-nuts/oxseUnhRtXM/unsubscribe>.
> To unsubscribe from this group and all its topics, send an email to 
> golang-nuts+unsubscr...@googlegroups.com 
> <mailto:golang-nuts+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/CAOyqgcUoC3-9X%3DRBYMt%3DSNgbkXG_%3DJ3hKM8j-QMc%3DLaKcEj_Dg%40mail.gmail.com
>  
> <https://groups.google.com/d/msgid/golang-nuts/CAOyqgcUoC3-9X%3DRBYMt%3DSNgbkXG_%3DJ3hKM8j-QMc%3DLaKcEj_Dg%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/8B9F4AD5-CAF7-4031-9860-01F9EBA8DA34%40snyk.io.

Reply via email to