Re: [PATCH] config: Conditionalize on LIBDEBUGINFOD instead of DEBUGINFOD
Hi Dmitry, On Mon, 2020-11-02 at 08:00 +, Dmitry V. Levin wrote: > When elfutils is configured using --enable-libdebuginfod > --disable-debuginfod, that is, when the library is built and > installed > but the server is not, it makes sense to install libdebuginfod.pc > because the latter complements the library rather than the server. > > Likewise, it makes sense to install profile.d/debuginfod.*sh files > along with libdebuginfod because the library can use DEBUGINFOD_URLS > environment variable as well as the server. > > This change does not affect --enable-debuginfod mode as the latter > requires --enable-libdebuginfod. Given the discussion and your followup patch to not define DEBUGINFOD_URLS environment variable unnecessarily I pushed your original patch. Thanks, Mark
Re: [PATCH 2/1] config: do not define DEBUGINFOD_URLS environment variable unnecessarily
Hi Dmitry, On Wed, 2020-11-04 at 08:00 +, Dmitry V. Levin wrote: > Before this change, when elfutils was configured without > --enable-debuginfod-urls, the installed profile.d/debuginfod.sh and > profile.d/debuginfod.csh scripts used to define the DEBUGINFOD_URLS > environment variable as an non-empty string containing spaces, making > all libdebuginfod users do extra work. > > Change these scripts to avoid defining the DEBUGINFOD_URLS environment > variable unless configured using --enable-debuginfod-urls. Looks good. Thanks for figuring out the csh variant. Pushed. Cheers, Mark
Re: [PATCH] libdwfl: Do not dlopen libdebuginfod if DEBUGINFOD_URLS is unset or empty
Hi Vitaly, On Thu, 2020-11-05 at 17:44 +0300, Vitaly Chikunov wrote: > Avoid calling expensive dlopen at the cost of an extra getenv check when > we already know it would not be needed. > > This mirrors the getenv check from debuginfod_query_server. I am sympathetic to this. It would have been a nicer way to fix the valgrind issue I recently had with dlopen having unsuppressible errors on some older glibc versions. But it also makes it so that an application can never use the debuginfod support afterwards. The current debuginfod_query_server check is late enough that an application could set DEBUGINFOD_URLS just before a Dwarf lookup. What do you think? Is that a valid use case? Should we maybe introduce setting debuginfod_urls on Dwfls so that an application can explicitly indicate they want to use debuginfod lookups and then dlopen libdebuginfod late? The problem with doing the dlopen late is that we also need libcurl and initializing libcurl (as done by libdebuginfod) is not thread-safe. Cheers, Mark
Re: [PATCH] libdwfl: Do not dlopen libdebuginfod if DEBUGINFOD_URLS is unset or empty
Hi - > [...] The problem with doing the dlopen late is that we also need > libcurl and initializing libcurl (as done by libdebuginfod) is not > thread-safe. >From reading libcurl code, and that of other clients, I still believe this concern was & is overrated. We could back down to simple debuginfod_begin time mutex-protected curl_global_init calls, and we'd be as fine as other applications. We could ditch the dlopen / dso-ctor issues entirely. - FChE
Indent and formatting of elfutils
Hi, I'm trying to compile elfutils with clang. I haven't written new code but moved code around. In this process source code formatting is lost when I moved couple of functions. Do you have any indent settings or clang-format or any auto settings ? Regards, Navin
Re: multi debug files and artificial module
Hi Sasha, On Thu, 2020-11-05 at 22:15 +, Sasha Da Rocha Pinheiro via Elfutils-devel wrote: > In libdw.h it says: /* The offset can be computed from the address. > */ > How do I get the CU DIE offset from the address? Only saving the > first CU and subtracting it on the others to get the offset? Yeah, that comment is correct, but not really that helpful. There are two offsets that might matter. The start of Dwarf (.debug_info) offset and the start of the Dwarf_CU offset. But getting either by hand is some work since it depends on the size of the CU header, which can be different based on the version and type of CU. You can get the header_size when iterating through the CUs with dwarf_nextcu or dwarf_next_unit but it is not easily available otherwise. But given a Dwarf_Die you can get the offsets through dwarf_dieoffset and dwarf_cuoffset. Also note that since 0.178 there is dwarf_die_addr_die, which simply takes the (main) Dwarf object and a Dwarf_Die addr. /* Given a Dwarf_Die addr returns a (reconstructed) Dwarf_Die, or NULL if the given addr didn't come from a valid Dwarf_Die. In particular it will make sure that the correct Dwarf_CU pointer is set for the Dwarf_Die, the Dwarf_Abbrev pointer will not be set up yet (it will only be once the Dwarf_Die is used to read attributes, children or siblings). This functions can be used to keep a reference to a Dwarf_Die which you want to refer to later. The addr, and the result of this function, is only valid while the associated Dwarf is valid. */ Although the comment doesn't explicitly say so, this also works for DIEs from the associated alt or split Dwarf objects associated with the given Dwarf. > When we go through the .debug_info using dwarf_nextcu, we are getting > partial units too. How should we deal with them? If they're not > actually CU, should they not be returned and only used internally by > libdw in order to 'complete' the other CUs? You should probably simply skip them because they will ultimately be imported into a "real" compile unit. Note that there also is dwarf_get_units () which will directly give you the unit_type (DW_UT_compile, DW_UT_type or DW_UT_partial) so you can easily skipe any you are not interested in. > It seems that libdw is automatically searching and loading the > supplemental dwz file. Given the following: > > ** file .debug ** > <1>: Abbrev Number: 37 (DW_TAG_subprogram) >DW_AT_abstract_origin: >DW_AT_low_pc : 0x8650 >DW_AT_high_pc : 229 >DW_AT_frame_base : 1 byte block: 9c > (DW_OP_call_frame_cfa) >DW_AT_GNU_all_call_sites: 1 >DW_AT_sibling : <0x107b> > ... > <4><5112>: Abbrev Number: 0 > > ** file dwz ** > <1><5112>: Abbrev Number: 81 (DW_TAG_subprogram) > <5113> DW_AT_external: 1 > <5113> DW_AT_name: (indirect string, offset: 0x9852): > iscsi_tcp_free_pdu > <5117> DW_AT_decl_file : 51 > <5118> DW_AT_decl_line : 142 > <5119> DW_AT_decl_column : 1 > <511a> DW_AT_prototyped : 1 > <511a> DW_AT_sibling : <0x5135> > > When I'm parsing f0d, libdw automatically fetches the abstract origin > on the dwz file. But when we try to parse the abstract origin on our > own it gives us the one in the same file, which is 0. Is it because > we should look into the form of the DW_AT_abstract_origin? In this > case seems to be the GNU_ref_alt, correct? Yes, if the form is DW_FORM_GNU_ref_alt (or DW_FORM_ref_sup4 or DW_FORM_ref_sup8 in DWARF5) then the "raw offset" is against the alt file (which you can get with dwarf_getalt). But I would recommend you simply use dwarf_formref_die to get the Dwarf_Die since that has all the logic already to resolve the DIE whether it is a "global" offset, a CU-relative offset, an alt-reference or a type signature. Cheers, Mark
Re: [PATCH] libelf: Update SH_ENTSIZE_HASH comment.
On Fri, 2020-11-06 at 18:33 +0100, Mark Wielaard wrote: > The elf-knowledge.h contains various macros to deal with specific ELF > knowledge needed to interpret some ELF constructs that can be ambigious > depending on architecture ABI. Update the comment of SH_ENTSIZE_HASH > to add a more technical description of why it is needed. Pushed.
Re: Indent and formatting of elfutils
Hi Navin, On Mon, 2020-11-09 at 22:03 +0530, Navin P via Elfutils-devel wrote: >I'm trying to compile elfutils with clang. >I haven't written new code but moved code around. In this process source > code formatting is lost when I moved couple of functions. > > Do you have any indent settings or clang-format or any auto settings ? Unfortunately (last time we checked) clang didn't support enough of the gnu99 standard to build elfutils. See the following comment for our configure check: # We use -std=gnu99 but have explicit checks for some language constructs # and GNU extensions since some compilers claim GNU99 support, but don't # really support all language extensions. In particular we need # Mixed Declarations and Code # https://gcc.gnu.org/onlinedocs/gcc/Mixed-Declarations.html # Nested Functions # https://gcc.gnu.org/onlinedocs/gcc/Nested-Functions.html # Arrays of Variable Length # https://gcc.gnu.org/onlinedocs/gcc/Variable-Length.html You might want to poke the clang developers to make sure they support those extended GNU C language features. As soon as they do, the configure check should succeed and you should be able to use the clang tools to build stuff. Cheers, Mark
