Page MenuHomeFreeBSD

Revert to the initial version of D24918
ClosedPublic

Authored by kib on May 21 2020, 5:30 PM.

Details

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)

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Skipped
Unit
Unit Tests Skipped
Build Status
Buildable 31221

Event Timeline

kib requested review of this revision.May 21 2020, 5:30 PM
cddl/contrib/opensolaris/lib/libdtrace/common/drti.c
149–150

This needs to change too.

kib marked an inline comment as done.

FIx bug pointed by Mark.

This fixes the problem for me.

sys/sys/link_elf.h
65

The patch got mangled somehow here.

lib/libc/gen/dlinfo.3
136

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.

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

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

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.

This revision was not accepted when it landed; it landed in state Needs Review.May 21 2020, 10:24 PM
This revision was automatically updated to reflect the committed changes.
lib/libc/gen/dlinfo.3
136

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.

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.