[Bug tools/28873] Implement eu-readelf -D
https://sourceware.org/bugzilla/show_bug.cgi?id=28873
--- Comment #8 from Mark Wielaard ---
(In reply to Aaron Merey from comment #7)
> This raises an interesting question: how do you calculate the number of
> symbols in .dynsym without using section headers?
>
> I figured there'd some kind of "DT_SYMTABNUM" value somewhere but
> unfortunately the answer doesn't appear to be so straightforward.
It has been proposed, but not (yet) adopted:
https://groups.google.com/g/generic-abi/c/9L03yrxXPBc
(sorry, a google groups link, there should be a normal archive, but I cannot
find it right now). If that was adopted and linkers would generate it, then
this question would indeed have a simple answer. Sadly, it isn't :{
> Judging from the binutils readelf source code you need to use information in
> the .hash and .gnu.hash sections to calculate the number of entries.
>
> To complicate things even more, a binary can contain either .hash or
> .gnu.hash or both and computing the number of .dynsym entries is different
> in each case. See binutils/readelf.c:get_num_dynamic_syms, you may need to
> implement some of this in your patch.
If there is a .hash section then it is fairly easy, the first word is the
number of symbols the hash/symbol table describes.
If it is a .gnu.hash section then sadly you have to parse and go through the
whole hashtable and count.
There is an implementation already in elfutils, but it is a bit hiden and
obscure if you don't know what you are looking for. Search for "Figure out the
size of the symbol table" in libdwfl/dwfl_module_getdwarf.c.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug libdw/30077] Duplicate definition of typedef struct debuginfod_client in libdwfl
https://sourceware.org/bugzilla/show_bug.cgi?id=30077
Mark Wielaard changed:
What|Removed |Added
CC||mark at klomp dot org
--- Comment #1 from Mark Wielaard ---
(In reply to David Edelsohn from comment #0)
> typedef struct debuginfod_client is defined in both libdwfl/libdwfl.h and in
> debuginfod.h included by libdwfl/libdwflP.h. Although innocuous, this is
> invalid C and causes compilation failures with strict compliance.
Is there a gcc flag that can help us detect this issue?
If the problem is that there cannot be two equal typedefs then we have to solve
this not just in the implementation code but also in the public headers.
If if understand the issue correctly then a program that includes both the
public debuginfod.h and dwfl.h headers (in any order or indirectly) has the
same problem?
Would the following fix it?
diff --git a/debuginfod/debuginfod.h.in b/debuginfod/debuginfod.h.in
index 69c9efd2..4a256ba9 100644
--- a/debuginfod/debuginfod.h.in
+++ b/debuginfod/debuginfod.h.in
@@ -44,7 +44,10 @@
#define DEBUGINFOD_SONAME "@LIBDEBUGINFOD_SONAME@"
/* Handle for debuginfod-client connection. */
+#ifndef _ELFUTILS_DEBUGINFOD_CLIENT_TYPEDEF
typedef struct debuginfod_client debuginfod_client;
+#define _ELFUTILS_DEBUGINFOD_CLIENT_TYPEDEF 1
+#endif
#ifdef __cplusplus
extern "C" {
diff --git a/libdwfl/libdwfl.h b/libdwfl/libdwfl.h
index 9114f7f0..49ad6664 100644
--- a/libdwfl/libdwfl.h
+++ b/libdwfl/libdwfl.h
@@ -50,7 +50,10 @@ typedef struct Dwfl_Thread Dwfl_Thread;
typedef struct Dwfl_Frame Dwfl_Frame;
/* Handle for debuginfod-client connection. */
+#ifndef _ELFUTILS_DEBUGINFOD_CLIENT_TYPEDEF
typedef struct debuginfod_client debuginfod_client;
+#define _ELFUTILS_DEBUGINFOD_CLIENT_TYPEDEF 1
+#endif
/* Callbacks. */
typedef struct
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug libdw/30077] Duplicate definition of typedef struct debuginfod_client in libdwfl
https://sourceware.org/bugzilla/show_bug.cgi?id=30077 Sam James changed: What|Removed |Added CC||sam at gentoo dot org --- Comment #2 from Sam James --- These issues sometimes appear with -flto -Wlto-type-mismatch but not clear that's the case here. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/30077] Duplicate definition of typedef struct debuginfod_client in libdwfl
https://sourceware.org/bugzilla/show_bug.cgi?id=30077
--- Comment #3 from David Edelsohn ---
The proposed patch in Comment #1 will work. It seems unfortunate for libdwfl.h
to define a struct that is part of debuginfod instead of using the debuginfod
header.
The struct is needed by libdwfl.h to prototype
extern debuginfod_client *dwfl_get_debuginfod_client (Dwfl *dwfl);
but that function is defined in debuginfod-client.c protected by
#ifdef ENABLE_LIBDEBUGINFOD
It already is protected where it is referenced by an existing macro. The
problem is the header logic doesn't match the logic in the file that uses that
prototype.
So, again, it would seem better to include the struct from debuginfod-client.h
directly instead of adding more macros to protect the headers and types that
already are protected. Something like:
--- libdwfl.h.orig 2023-02-03 15:03:57.669810336 -0500
+++ libdwfl.h 2023-02-04 16:57:05.734206129 -0500
@@ -49,9 +49,6 @@
PC location described by an FDE belonging to Dwfl_Thread. */
typedef struct Dwfl_Frame Dwfl_Frame;
-/* Handle for debuginfod-client connection. */
-typedef struct debuginfod_client debuginfod_client;
-
/* Callbacks. */
typedef struct
{
@@ -808,12 +805,16 @@
int dwfl_frame_reg (Dwfl_Frame *state, unsigned regno, Dwarf_Word *val)
__nonnull_attribute__ (1);
+#ifdef ENABLE_LIBDEBUGINFOD
+#include "../debuginfod/debuginfod.h"
+
/* Return the internal debuginfod-client connection handle for the DWFL
session.
When the client connection has not yet been initialized, it will be done on
the
first call to this function. If elfutils is compiled without support for
debuginfod,
NULL will be returned.
*/
extern debuginfod_client *dwfl_get_debuginfod_client (Dwfl *dwfl);
+#endif
#ifdef __cplusplus
}
That defines the struct in only one place (debuginfod.h) and includes the
header and prototype with the same macro protecting its use in
debuginfod-client.c.
--
You are receiving this mail because:
You are on the CC list for the bug.
