Parsing 32 bit Go binaries causes large memory allocations

[ddelnano]

In order to attach uprobes to Go binaries, Pixie needs to detect what version of go the application was compiled with (source). There was a recent bug where certain Go binaries caused memory allocation errors (#1111).

While that bug was fixed by enforcing an upper bound on its memory allocations, the underlying cause is due to our inability to properly parse 32 bit go binaries. We use a hard coded size for the runtime.buildVersion ELF symbol. This value is correct for 64 bit binaries but is too large for 32 bit binaries and results in Pixie reading garbage memory. The objdump commands below show that this symbol is 8 bytes for 32 bit binaries and 16 bytes for 64 bit binaries:

$ objdump -Tt main \| grep runtime.buildVersion
objdump: main: not a dynamic object
0000000000525f50 g     O .data  0000000000000010 runtime.buildVersion      <------ 0x10 in size
00000000004b72d8 g     O .rodata        0000000000000009 runtime.buildVersion.str
$ objdump -Tt main-i386 \| grep runtime.buildVersion
objdump: main-i386: not a dynamic object
08166628 g     O .data  00000008 runtime.buildVersion                      <------ 0x8 in size
080f8160 g     O .rodata        00000009 runtime.buildVersion.str

We need to update our ELF parsing and tests to verify that we can properly detect Go's build version for 32 bit binaries.