glibc/bits/dl_find_object.h

/* System dependent definitions for finding objects by address.
   Copyright (C) 2021 Free Software Foundation, Inc.
   This file is part of the GNU C Library.

   The GNU C Library is free software; you can redistribute it and/or
   modify it under the terms of the GNU Lesser General Public
   License as published by the Free Software Foundation; either
   version 2.1 of the License, or (at your option) any later version.

   The GNU C Library is distributed in the hope that it will be useful,
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
   Lesser General Public License for more details.

   You should have received a copy of the GNU Lesser General Public
   License along with the GNU C Library; if not, see
   <https://www.gnu.org/licenses/>.  */

#ifndef _DLFCN_H
# error "Never use <bits/dl_find_object.h> directly; include <dlfcn.h> instead."
#endif

/* This implementation does not have a dlfo_eh_dbase member in struct
   dl_find_object.  */
#define DLFO_STRUCT_HAS_EH_DBASE 0

/* This implementation does not have a dlfo_eh_count member in struct
   dl_find_object.  */
#define DLFO_STRUCT_HAS_EH_COUNT 0

/* The ELF segment which contains the exception handling data.  */
#define DLFO_EH_SEGMENT_TYPE PT_GNU_EH_FRAME
elf: Add _dl_find_object function It can be used to speed up the libgcc unwinder, and the internal _dl_find_dso_for_object function (which is used for caller identification in dlopen and related functions, and in dladdr). _dl_find_object is in the internal namespace due to bug 28503. If libgcc switches to _dl_find_object, this namespace issue will be fixed. It is located in libc for two reasons: it is necessary to forward the call to the static libc after static dlopen, and there is a link ordering issue with -static-libgcc and libgcc_eh.a because libc.so is not a linker script that includes ld.so in the glibc build tree (so that GCC's internal -lc after libgcc_eh.a does not pick up ld.so). It is necessary to do the i386 customization in the sysdeps/x86/bits/dl_find_object.h header shared with x86-64 because otherwise, multilib installations are broken. The implementation uses software transactional memory, as suggested by Torvald Riegel. Two copies of the supporting data structures are used, also achieving full async-signal-safety. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org> 2021-12-28 21:52:56 +00:00			`/* System dependent definitions for finding objects by address.`
			`Copyright (C) 2021 Free Software Foundation, Inc.`
			`This file is part of the GNU C Library.`

			`The GNU C Library is free software; you can redistribute it and/or`
			`modify it under the terms of the GNU Lesser General Public`
			`License as published by the Free Software Foundation; either`
			`version 2.1 of the License, or (at your option) any later version.`

			`The GNU C Library is distributed in the hope that it will be useful,`
			`but WITHOUT ANY WARRANTY; without even the implied warranty of`
			`MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU`
			`Lesser General Public License for more details.`

			`You should have received a copy of the GNU Lesser General Public`
			`License along with the GNU C Library; if not, see`
			`<https://www.gnu.org/licenses/>. */`

			`#ifndef _DLFCN_H`
			`# error "Never use <bits/dl_find_object.h> directly; include <dlfcn.h> instead."`
			`#endif`

			`/* This implementation does not have a dlfo_eh_dbase member in struct`
			`dl_find_object. */`
			`#define DLFO_STRUCT_HAS_EH_DBASE 0`

			`/* This implementation does not have a dlfo_eh_count member in struct`
			`dl_find_object. */`
			`#define DLFO_STRUCT_HAS_EH_COUNT 0`

			`/* The ELF segment which contains the exception handling data. */`
			`#define DLFO_EH_SEGMENT_TYPE PT_GNU_EH_FRAME`