Revert to the initial version of D24918

[kib]

Summary

Keep link_map l_addr binary layout compatible, rename l_addr to l_base where rtld returns map base.
Provide relocbase in newly added l_addr.

Reported by: antoine (portmgr)

[markj]

cddl/contrib/opensolaris/lib/libdtrace/common/drti.c

146 ↗

(On Diff #72081)

This needs to change too.

[kib]

FIx bug pointed by Mark.

[markj]

This fixes the problem for me.

sys/sys/link_elf.h

63 ↗

(On Diff #72082)

The patch got mangled somehow here.

[kib]

Fix the patch.

[emaste]

lib/libc/gen/dlinfo.3

136 ↗

(On Diff #72083)

I wonder if it's worth a note here about other operating systems? I wouldn't want to say "Linux does this, Solaris does this" because it's not our place and might get out of date. But maybe a note that other operating systems implement these perhaps with different semantics? I don't mind taking a stab at a suitable note after you commit this.

[jhb]

GDB will work with this ok. (It will still use l_base as it's l_addr, but that's ok)

[kib]

In D24946#549258, @jhb wrote:

GDB will work with this ok. (It will still use l_base as it's l_addr, but that's ok)

Recompiled gdb would use new l_addr, isn't it ?

lib/libc/gen/dlinfo.3

136 ↗

(On Diff #72083)

I verified that Linux does the same as our 'new' l_addr, but I am not sure about Solaris.
This review started because apparently dtrace depends on the old behavior, and Mark stated that the code is not changed against Solaris origin.

I was not able to find a Solaris box with fresh clang/lld to test (I cannot easily build a specific dso needed for test with GNU ld, and I do not have Solaris available at all). I do not block this fix while searching for a way to test Solaris.

[emaste]

lib/libc/gen/dlinfo.3

136 ↗

(On Diff #72083)

Exactly, I don't want to have a treatise on these fields in all operating systems - primarily a caution that these may behave differently on different operating systems so pay careful attention to the descriptions.

[jhb]

In D24946#549323, @kib wrote:

In D24946#549258, @jhb wrote:

GDB will work with this ok. (It will still use l_base as it's l_addr, but that's ok)

Recompiled gdb would use new l_addr, isn't it ?

No, it doesn't use the source layout. Instead, it uses functions that determine the binary layout so that it works for cross-debugging. This is part of why removing l_offs (now l_xxx) for MIPS would be such a PITA. For example, all of the non-MIPS architectures on FreeBSD use these functions to describe the layout of 'struct link_map':

https://github.com/bsdjhb/gdb/blob/master/gdb/solib-svr4.c#L3160 and https://github.com/bsdjhb/gdb/blob/master/gdb/solib-svr4.c#L3192

MIPS on FreeBSD uses its own versions of these functions that account for l_offs:

https://github.com/bsdjhb/gdb/blob/master/gdb/mips-fbsd-tdep.c#L465

Note that these files are all "non-native" meaning they get compiled on FreeBSD/amd64 hosts as well as Linux or OS X or Windows hosts to permit cross-debugging of process cores which is why they do not use the native structure at all, but instead hardcode knowledge about the layout of those structures.