Re: PIE binaries are no longer mapped below 4 GiB on ppc64le
Alan Modra writes:
> On Thu, Nov 01, 2018 at 02:55:34PM +1100, Michael Ellerman wrote:
>> Hi Florian,
>>
>> Florian Weimer writes:
>> > We tried to use Go to build PIE binaries, and while the Go toolchain is
>> > definitely not ready (it produces text relocations and problematic
>> > relocations in general), it exposed what could be an accidental
>> > userspace ABI change.
>> >
>> > With our 4.10-derived kernel, PIE binaries are mapped below 4 GiB, so
>> > relocations like R_PPC64_ADDR16_HA work:
>> >
>> > 21f0-220d r-xp fd:00 36593493
>> > /root/extld
>> > 220d-220e r--p 001c fd:00 36593493
>> > /root/extld
>> > 220e-2210 rw-p 001d fd:00 36593493
>> > /root/extld
>> ...
>> >
>> > With a 4.18-derived kernel (with the hashed mm), we get this instead:
>> >
>> > 120e6-12103 rw-p fd:00 102447141
>> > /root/extld
>> > 12103-12106 rw-p 001c fd:00 102447141
>> > /root/extld
>> > 12106-12108 rw-p 00:00 0
>>
>> I assume that's caused by:
>>
>> 47ebb09d5485 ("powerpc: move ELF_ET_DYN_BASE to 4GB / 4MB")
>>
>> Which did roughly:
>>
>> -#define ELF_ET_DYN_BASE 0x2000
>> +#define ELF_ET_DYN_BASE (is_32bit_task() ? 0x00040UL : \
>> + 0x1UL)
>>
>> And went into 4.13.
>>
>> > ...
>> > I'm not entirely sure what to make of this, but I'm worried that this
>> > could be a regression that matters to userspace.
>>
>> It was a deliberate change, and it seemed to not break anything so we
>> merged it. But obviously we didn't test widely enough.
>>
>> So I guess it clearly can matter to userspace, and it used to work, so
>> therefore it is a regression.
>>
>> But at the same time we haven't had any other reports of breakage, so is
>> this somehow specific to something Go is doing? Or did we just get lucky
>> up until now? Or is no one actually testing on Power? ;)
>
> Mapping PIEs above 4G should be fine. It works for gcc C and C++
> after all. The problem is that ppc64le Go is generating code not
> suitable for a PIE. Dynamic text relocations are evidence of non-PIC
> object files.
>
> Quoting Lynn Boger :
> "When building a pie binary with golang, they should be using
> -buildmode=pie and not just pass -pie to the linker".
Thanks Alan.
So this isn't a kernel bug per se, but the the old behaviour falls in
the category of "shouldn't have worked but did by accident", and so the
question is just how wide spread is the userspace breakage.
At least so far it seems not very wide spread, so we'll leave things as
they are for now. As Florian said we can always add a personality flag
in future if we need to.
cheers
Re: PIE binaries are no longer mapped below 4 GiB on ppc64le
Florian Weimer writes:
> * Michael Ellerman:
>
>> Hi Florian,
>>
>> Florian Weimer writes:
>>> We tried to use Go to build PIE binaries, and while the Go toolchain is
>>> definitely not ready (it produces text relocations and problematic
>>> relocations in general), it exposed what could be an accidental
>>> userspace ABI change.
>>>
>>> With our 4.10-derived kernel, PIE binaries are mapped below 4 GiB, so
>>> relocations like R_PPC64_ADDR16_HA work:
>>>
>>> 21f0-220d r-xp fd:00 36593493
>>> /root/extld
>>> 220d-220e r--p 001c fd:00 36593493
>>> /root/extld
>>> 220e-2210 rw-p 001d fd:00 36593493
>>> /root/extld
>> ...
>>>
>>> With a 4.18-derived kernel (with the hashed mm), we get this instead:
>>>
>>> 120e6-12103 rw-p fd:00 102447141
>>> /root/extld
>>> 12103-12106 rw-p 001c fd:00 102447141
>>> /root/extld
>>> 12106-12108 rw-p 00:00 0
>>
>> I assume that's caused by:
>>
>> 47ebb09d5485 ("powerpc: move ELF_ET_DYN_BASE to 4GB / 4MB")
>>
>> Which did roughly:
>>
>> -#define ELF_ET_DYN_BASE 0x2000
>> +#define ELF_ET_DYN_BASE (is_32bit_task() ? 0x00040UL : \
>> + 0x1UL)
>>
>> And went into 4.13.
>>
>>> ...
>>> I'm not entirely sure what to make of this, but I'm worried that this
>>> could be a regression that matters to userspace.
>>
>> It was a deliberate change, and it seemed to not break anything so we
>> merged it. But obviously we didn't test widely enough.
>
> * Michael Ellerman:
>
>>> I'm not entirely sure what to make of this, but I'm worried that this
>>> could be a regression that matters to userspace.
>>
>> It was a deliberate change, and it seemed to not break anything so we
>> merged it. But obviously we didn't test widely enough.
>
> Thanks for moving back the discussion to kernel matters. 8-)
I don't know anything about toolchains so I can't comment on that part
of the thread :)
>> So I guess it clearly can matter to userspace, and it used to work, so
>> therefore it is a regression.
>
> Is there a knob to get back the old base address?
No.
>> But at the same time we haven't had any other reports of breakage, so is
>> this somehow specific to something Go is doing?
>
> Go uses 32-bit run-time relocations which (I think) were primarily
> designed as link-time relocations for programs mapped under 4 GiB. It's
> amazing that the binaries work at all under old kernels. On other
> targets, the link editor refuses to produce an executable, or may even
> produce a binary which crashes at run time.
>
>> Or did we just get lucky up until now? Or is no one actually testing
>> on Power? ;)
>
> I'm not too worried about it. It looks like a well-understood change to
> me. The glibc dynamic linker prints a reasonably informative error
> message (in the sense that it doesn't crash without printing anything).
> I think we can wait and see if someone comes up with a more compelling
> case for backwards compatibility than the broken Go binaries (which we
> will rebuild anyway because we don't want text relocations). I assume
> that it will be possible to add a personality flag if it ever proves
> necessary—or maybe map the executable below 4 GiB in case of ASLR is
> disabled, so that people have at least a workaround to get old binaries
> going again.
Yeah we could do something like that if it becomes necessary.
I've actually wondered in the past if we should have an explicit syscall
for configuring this sort of address space layout stuff. For example
we always put mmaps at ~128T and growing down, even though we have free
address space above that, and there's no way to control that.
> But right now, that doesn't seem necessary.
OK thanks.
cheers
Re: PIE binaries are no longer mapped below 4 GiB on ppc64le
* Michael Ellerman:
> Hi Florian,
>
> Florian Weimer writes:
>> We tried to use Go to build PIE binaries, and while the Go toolchain is
>> definitely not ready (it produces text relocations and problematic
>> relocations in general), it exposed what could be an accidental
>> userspace ABI change.
>>
>> With our 4.10-derived kernel, PIE binaries are mapped below 4 GiB, so
>> relocations like R_PPC64_ADDR16_HA work:
>>
>> 21f0-220d r-xp fd:00 36593493
>> /root/extld
>> 220d-220e r--p 001c fd:00 36593493
>> /root/extld
>> 220e-2210 rw-p 001d fd:00 36593493
>> /root/extld
> ...
>>
>> With a 4.18-derived kernel (with the hashed mm), we get this instead:
>>
>> 120e6-12103 rw-p fd:00 102447141
>> /root/extld
>> 12103-12106 rw-p 001c fd:00 102447141
>> /root/extld
>> 12106-12108 rw-p 00:00 0
>
> I assume that's caused by:
>
> 47ebb09d5485 ("powerpc: move ELF_ET_DYN_BASE to 4GB / 4MB")
>
> Which did roughly:
>
> -#define ELF_ET_DYN_BASE0x2000
> +#define ELF_ET_DYN_BASE(is_32bit_task() ? 0x00040UL : \
> + 0x1UL)
>
> And went into 4.13.
>
>> ...
>> I'm not entirely sure what to make of this, but I'm worried that this
>> could be a regression that matters to userspace.
>
> It was a deliberate change, and it seemed to not break anything so we
> merged it. But obviously we didn't test widely enough.
* Michael Ellerman:
>> I'm not entirely sure what to make of this, but I'm worried that this
>> could be a regression that matters to userspace.
>
> It was a deliberate change, and it seemed to not break anything so we
> merged it. But obviously we didn't test widely enough.
Thanks for moving back the discussion to kernel matters. 8-)
> So I guess it clearly can matter to userspace, and it used to work, so
> therefore it is a regression.
Is there a knob to get back the old base address?
> But at the same time we haven't had any other reports of breakage, so is
> this somehow specific to something Go is doing?
Go uses 32-bit run-time relocations which (I think) were primarily
designed as link-time relocations for programs mapped under 4 GiB. It's
amazing that the binaries work at all under old kernels. On other
targets, the link editor refuses to produce an executable, or may even
produce a binary which crashes at run time.
> Or did we just get lucky up until now? Or is no one actually testing
> on Power? ;)
I'm not too worried about it. It looks like a well-understood change to
me. The glibc dynamic linker prints a reasonably informative error
message (in the sense that it doesn't crash without printing anything).
I think we can wait and see if someone comes up with a more compelling
case for backwards compatibility than the broken Go binaries (which we
will rebuild anyway because we don't want text relocations). I assume
that it will be possible to add a personality flag if it ever proves
necessary—or maybe map the executable below 4 GiB in case of ASLR is
disabled, so that people have at least a workaround to get old binaries
going again.
But right now, that doesn't seem necessary.
Thanks,
Florian
Re: PIE binaries are no longer mapped below 4 GiB on ppc64le
On Thu, Nov 01, 2018 at 02:55:34PM +1100, Michael Ellerman wrote:
> Hi Florian,
>
> Florian Weimer writes:
> > We tried to use Go to build PIE binaries, and while the Go toolchain is
> > definitely not ready (it produces text relocations and problematic
> > relocations in general), it exposed what could be an accidental
> > userspace ABI change.
> >
> > With our 4.10-derived kernel, PIE binaries are mapped below 4 GiB, so
> > relocations like R_PPC64_ADDR16_HA work:
> >
> > 21f0-220d r-xp fd:00 36593493
> > /root/extld
> > 220d-220e r--p 001c fd:00 36593493
> > /root/extld
> > 220e-2210 rw-p 001d fd:00 36593493
> > /root/extld
> ...
> >
> > With a 4.18-derived kernel (with the hashed mm), we get this instead:
> >
> > 120e6-12103 rw-p fd:00 102447141
> > /root/extld
> > 12103-12106 rw-p 001c fd:00 102447141
> > /root/extld
> > 12106-12108 rw-p 00:00 0
>
> I assume that's caused by:
>
> 47ebb09d5485 ("powerpc: move ELF_ET_DYN_BASE to 4GB / 4MB")
>
> Which did roughly:
>
> -#define ELF_ET_DYN_BASE0x2000
> +#define ELF_ET_DYN_BASE(is_32bit_task() ? 0x00040UL : \
> + 0x1UL)
>
> And went into 4.13.
>
> > ...
> > I'm not entirely sure what to make of this, but I'm worried that this
> > could be a regression that matters to userspace.
>
> It was a deliberate change, and it seemed to not break anything so we
> merged it. But obviously we didn't test widely enough.
>
> So I guess it clearly can matter to userspace, and it used to work, so
> therefore it is a regression.
>
> But at the same time we haven't had any other reports of breakage, so is
> this somehow specific to something Go is doing? Or did we just get lucky
> up until now? Or is no one actually testing on Power? ;)
Mapping PIEs above 4G should be fine. It works for gcc C and C++
after all. The problem is that ppc64le Go is generating code not
suitable for a PIE. Dynamic text relocations are evidence of non-PIC
object files.
Quoting Lynn Boger :
"When building a pie binary with golang, they should be using
-buildmode=pie and not just pass -pie to the linker".
--
Alan Modra
Australia Development Lab, IBM
Re: PIE binaries are no longer mapped below 4 GiB on ppc64le
Hi Florian,
Florian Weimer writes:
> We tried to use Go to build PIE binaries, and while the Go toolchain is
> definitely not ready (it produces text relocations and problematic
> relocations in general), it exposed what could be an accidental
> userspace ABI change.
>
> With our 4.10-derived kernel, PIE binaries are mapped below 4 GiB, so
> relocations like R_PPC64_ADDR16_HA work:
>
> 21f0-220d r-xp fd:00 36593493
> /root/extld
> 220d-220e r--p 001c fd:00 36593493
> /root/extld
> 220e-2210 rw-p 001d fd:00 36593493
> /root/extld
...
>
> With a 4.18-derived kernel (with the hashed mm), we get this instead:
>
> 120e6-12103 rw-p fd:00 102447141
> /root/extld
> 12103-12106 rw-p 001c fd:00 102447141
> /root/extld
> 12106-12108 rw-p 00:00 0
I assume that's caused by:
47ebb09d5485 ("powerpc: move ELF_ET_DYN_BASE to 4GB / 4MB")
Which did roughly:
-#define ELF_ET_DYN_BASE 0x2000
+#define ELF_ET_DYN_BASE (is_32bit_task() ? 0x00040UL : \
+0x1UL)
And went into 4.13.
> ...
> I'm not entirely sure what to make of this, but I'm worried that this
> could be a regression that matters to userspace.
It was a deliberate change, and it seemed to not break anything so we
merged it. But obviously we didn't test widely enough.
So I guess it clearly can matter to userspace, and it used to work, so
therefore it is a regression.
But at the same time we haven't had any other reports of breakage, so is
this somehow specific to something Go is doing? Or did we just get lucky
up until now? Or is no one actually testing on Power? ;)
cheers
Re: PIE binaries are no longer mapped below 4 GiB on ppc64le
On Wed, 31 Oct 2018 19:04:14 -0300 Tulio Magno Quites Machado Filho wrote: > Florian Weimer writes: > > > * Tulio Magno Quites Machado Filho: > > > >> I wonder if this is restricted to linker that Golang uses. > >> Were you able to reproduce the same problem with Binutils' > >> linker? > > > > The example is carefully constructed to use the external linker. It > > invokes gcc, which then invokes the BFD linker in my case. > > Indeed. That question was unnecessary. :-D > > > Based on the relocations, I assume there is only so much the linker > > can do here. I'm amazed that it produces an executable at all, let > > alone one that runs correctly on some kernel versions! > > Agreed. That isn't expected to work. Both the compiler and the > linker have to generate PIE for it to work. > > > I assume that the Go toolchain simply lacks PIE support on > > ppc64le. > > Maybe the support is there, but it doesn't generate PIC by default? > golang has -fPIC IIRC. It does not benefit from the GNU toolchian synergy of always calling the linker with the correct flags corresponding to the generated code, though. So when gcc flips the switch default value golang happily produces incompatible objects. Also I suspect some pieces of stdlib are not compiled with the flags you pass in for the build so there are always some objects somewhere that are not compatible. Thanks Michal
Re: PIE binaries are no longer mapped below 4 GiB on ppc64le
On Wed, 2018-10-31 at 18:54 +0100, Florian Weimer wrote: > > It would matter to C code which returns the address of a global variable > in the main program through and (implicit) int return value. > > The old behavior hid some pointer truncation issues. Hiding bugs like that is never a good idea.. > > Maybe it would be good idea to generate 64bit relocations on 64bit > > targets? > > Yes, the Go toolchain definitely needs fixing for PIE. I don't dispute > that. There was never any ABI guarantee that programs would be loaded below 4G... it just *happened*, so that's not per-se an ABI change. That said, I'm surprised of the choice of address.. I would have rather moved to above 1TB to benefit from 1T segments... Nick, Anton, do you know anything about that change ? Ben.
Re: PIE binaries are no longer mapped below 4 GiB on ppc64le
Florian Weimer writes: > * Tulio Magno Quites Machado Filho: > >> I wonder if this is restricted to linker that Golang uses. >> Were you able to reproduce the same problem with Binutils' linker? > > The example is carefully constructed to use the external linker. It > invokes gcc, which then invokes the BFD linker in my case. Indeed. That question was unnecessary. :-D > Based on the relocations, I assume there is only so much the linker can > do here. I'm amazed that it produces an executable at all, let alone > one that runs correctly on some kernel versions! Agreed. That isn't expected to work. Both the compiler and the linker have to generate PIE for it to work. > I assume that the Go toolchain simply lacks PIE support on ppc64le. Maybe the support is there, but it doesn't generate PIC by default? -- Tulio Magno
Re: PIE binaries are no longer mapped below 4 GiB on ppc64le
Florian Weimer writes: > * Michal Suchánek: > >> On Wed, 31 Oct 2018 18:20:56 +0100 >> Florian Weimer wrote: >> >>> And it needs to be built with: >>> >>> go build -ldflags=-extldflags=-pie extld.go >>> >>> I'm not entirely sure what to make of this, but I'm worried that this >>> could be a regression that matters to userspace. >> >> I encountered the same when trying to build go on ppc64le. I am not >> familiar with the internals so I just let it be. >> >> It does not seem to matter to any other userspace. > > It would matter to C code which returns the address of a global variable > in the main program through and (implicit) int return value. I wonder if this is restricted to linker that Golang uses. Were you able to reproduce the same problem with Binutils' linker? -- Tulio Magno
Re: PIE binaries are no longer mapped below 4 GiB on ppc64le
* Tulio Magno Quites Machado Filho: > Florian Weimer writes: > >> * Michal Suchánek: >> >>> On Wed, 31 Oct 2018 18:20:56 +0100 >>> Florian Weimer wrote: >>> And it needs to be built with: go build -ldflags=-extldflags=-pie extld.go I'm not entirely sure what to make of this, but I'm worried that this could be a regression that matters to userspace. >>> >>> I encountered the same when trying to build go on ppc64le. I am not >>> familiar with the internals so I just let it be. >>> >>> It does not seem to matter to any other userspace. >> >> It would matter to C code which returns the address of a global variable >> in the main program through and (implicit) int return value. > > I wonder if this is restricted to linker that Golang uses. > Were you able to reproduce the same problem with Binutils' linker? The example is carefully constructed to use the external linker. It invokes gcc, which then invokes the BFD linker in my case. Based on the relocations, I assume there is only so much the linker can do here. I'm amazed that it produces an executable at all, let alone one that runs correctly on some kernel versions! I assume that the Go toolchain simply lacks PIE support on ppc64le. Thanks, Florian
Re: PIE binaries are no longer mapped below 4 GiB on ppc64le
* Michal Suchánek: > On Wed, 31 Oct 2018 18:20:56 +0100 > Florian Weimer wrote: > >> We tried to use Go to build PIE binaries, and while the Go toolchain >> is definitely not ready (it produces text relocations and problematic >> relocations in general), it exposed what could be an accidental >> userspace ABI change. >> >> With our 4.10-derived kernel, PIE binaries are mapped below 4 GiB, so >> relocations like R_PPC64_ADDR16_HA work: >> > ... > >> There are fewer mappings because the loader detects a relocation >> overflow and aborts (“error while loading shared libraries: >> R_PPC64_ADDR16_HA reloc at 0x000120f0983c for symbol `' out of >> range”), so I had to recover the mappings externally. Disabling ASLR >> does not help. >> > ... >> >> And it needs to be built with: >> >> go build -ldflags=-extldflags=-pie extld.go >> >> I'm not entirely sure what to make of this, but I'm worried that this >> could be a regression that matters to userspace. > > I encountered the same when trying to build go on ppc64le. I am not > familiar with the internals so I just let it be. > > It does not seem to matter to any other userspace. It would matter to C code which returns the address of a global variable in the main program through and (implicit) int return value. The old behavior hid some pointer truncation issues. > Maybe it would be good idea to generate 64bit relocations on 64bit > targets? Yes, the Go toolchain definitely needs fixing for PIE. I don't dispute that. Thanks, Florian
Re: PIE binaries are no longer mapped below 4 GiB on ppc64le
On Wed, 31 Oct 2018 18:20:56 +0100 Florian Weimer wrote: > We tried to use Go to build PIE binaries, and while the Go toolchain > is definitely not ready (it produces text relocations and problematic > relocations in general), it exposed what could be an accidental > userspace ABI change. > > With our 4.10-derived kernel, PIE binaries are mapped below 4 GiB, so > relocations like R_PPC64_ADDR16_HA work: > ... > There are fewer mappings because the loader detects a relocation > overflow and aborts (“error while loading shared libraries: > R_PPC64_ADDR16_HA reloc at 0x000120f0983c for symbol `' out of > range”), so I had to recover the mappings externally. Disabling ASLR > does not help. > ... > > And it needs to be built with: > > go build -ldflags=-extldflags=-pie extld.go > > I'm not entirely sure what to make of this, but I'm worried that this > could be a regression that matters to userspace. I encountered the same when trying to build go on ppc64le. I am not familiar with the internals so I just let it be. It does not seem to matter to any other userspace. Maybe it would be good idea to generate 64bit relocations on 64bit targets? Thanks Michal
PIE binaries are no longer mapped below 4 GiB on ppc64le
We tried to use Go to build PIE binaries, and while the Go toolchain is
definitely not ready (it produces text relocations and problematic
relocations in general), it exposed what could be an accidental
userspace ABI change.
With our 4.10-derived kernel, PIE binaries are mapped below 4 GiB, so
relocations like R_PPC64_ADDR16_HA work:
21f0-220d r-xp fd:00 36593493
/root/extld
220d-220e r--p 001c fd:00 36593493
/root/extld
220e-2210 rw-p 001d fd:00 36593493
/root/extld
2210-2212 rw-p 00:00 0
264b-264e rw-p 00:00 0 [heap]
c0-c1 rw-p 00:00 0
c41ffe-c42030 rw-p 00:00 0
3fff8c00-3fff8c03 rw-p 00:00 0
3fff8c03-3fff9000 ---p 00:00 0
3fff9000-3fff9003 rw-p 00:00 0
3fff9003-3fff9400 ---p 00:00 0
3fff9400-3fff9403 rw-p 00:00 0
3fff9403-3fff9800 ---p 00:00 0
3fff9800-3fff9803 rw-p 00:00 0
3fff9803-3fff9c00 ---p 00:00 0
3fff9c00-3fff9c03 rw-p 00:00 0
3fff9c03-3fffa000 ---p 00:00 0
3fffa229-3fffa22d rw-p 00:00 0
3fffa22d-3fffa22e ---p 00:00 0
3fffa22e-3fffa2ae rw-p 00:00 0
3fffa2ae-3fffa2af ---p 00:00 0
3fffa2af-3fffa32f rw-p 00:00 0
3fffa32f-3fffa330 ---p 00:00 0
3fffa330-3fffa3b0 rw-p 00:00 0
3fffa3b0-3fffa3b1 ---p 00:00 0
3fffa3b1-3fffa431 rw-p 00:00 0
3fffa431-3fffa432 ---p 00:00 0
3fffa432-3fffa4bb rw-p 00:00 0
3fffa4bb-3fffa4da r-xp fd:00 34316081
/usr/lib64/power9/libc-2.28.so
3fffa4da-3fffa4db r--p 001e fd:00 34316081
/usr/lib64/power9/libc-2.28.so
3fffa4db-3fffa4dc rw-p 001f fd:00 34316081
/usr/lib64/power9/libc-2.28.so
3fffa4dc-3fffa4df r-xp fd:00 34316085
/usr/lib64/power9/libpthread-2.28.so
3fffa4df-3fffa4e0 r--p 0002 fd:00 34316085
/usr/lib64/power9/libpthread-2.28.so
3fffa4e0-3fffa4e1 rw-p 0003 fd:00 34316085
/usr/lib64/power9/libpthread-2.28.so
3fffa4e1-3fffa4e2 rw-p 00:00 0
3fffa4e2-3fffa4e4 r-xp 00:00 0 [vdso]
3fffa4e4-3fffa4e7 r-xp fd:00 874114
/usr/lib64/ld-2.28.so
3fffa4e7-3fffa4e8 r--p 0002 fd:00 874114
/usr/lib64/ld-2.28.so
3fffa4e8-3fffa4e9 rw-p 0003 fd:00 874114
/usr/lib64/ld-2.28.so
3300-3303 rw-p 00:00 0
[stack]
With a 4.18-derived kernel (with the hashed mm), we get this instead:
120e6-12103 rw-p fd:00 102447141
/root/extld
12103-12106 rw-p 001c fd:00 102447141
/root/extld
12106-12108 rw-p 00:00 0
7fffb5b0-7fffb5cf r-xp fd:00 67169871
/usr/lib64/power9/libc-2.28.so
7fffb5cf-7fffb5d0 r--p 001e fd:00 67169871
/usr/lib64/power9/libc-2.28.so
7fffb5d0-7fffb5d1 rw-p 001f fd:00 67169871
/usr/lib64/power9/libc-2.28.so
7fffb5d1-7fffb5d4 r-xp fd:00 67169875
/usr/lib64/power9/libpthread-2.28.so
7fffb5d4-7fffb5d5 r--p 0002 fd:00 67169875
/usr/lib64/power9/libpthread-2.28.so
7fffb5d5-7fffb5d6 rw-p 0003 fd:00 67169875
/usr/lib64/power9/libpthread-2.28.so
7fffb5d6-7fffb5d7 r--p fd:00 67780267
/etc/ld.so.cache
7fffb5d7-7fffb5d9 r-xp 00:00 0 [vdso]
7fffb5d9-7fffb5dc r-xp fd:00 1477
/usr/lib64/ld-2.28.so
7fffb5dc-7fffb5de rw-p 0002 fd:00 1477
/usr/lib64/ld-2.28.so
7f6c-7f6f rw-p 00:00 0 [stack]
There are fewer mappings because the loader detects a relocation
overflow and aborts (“error while loading shared libraries:
R_PPC64_ADDR16_HA reloc at 0x000120f0983c for symbol `' out of
range”), so I had to recover the mappings externally. Disabling ASLR
does not help.
The Go program looks like this:
package main
import (
"fmt"
"io/ioutil"
"os"
)
// #include
import "C"
func main() {
// Force external linking against glibc.
fmt.Printf("%#v\n", C.GoString(C.gnu_get_libc_version()))
maps, err := os.Open("/proc/self/maps")
if err != nil {
panic(err)
}
defer maps.Close()
