Revert to the initial version of D24918
ClosedPublic
Actions

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.

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 ↗	(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.

This revision was not accepted when it landed; it landed in state Needs Review.May 21 2020, 10:24 PM

Closed by commit rS361349: Restore the binary compatibility for link_map l_addr. (authored by kib). · Explain Why

This revision was automatically updated to reflect the committed changes.

kib added a commit: rS361349: Restore the binary compatibility for link_map l_addr..

emaste added inline comments.May 21 2020, 10:31 PM

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.

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.