[Bug general/31439] error: undefined reference to '__dwarf_get_units_internal'
https://sourceware.org/bugzilla/show_bug.cgi?id=31439 Mark Wielaard changed: What|Removed |Added CC||mark at klomp dot org --- Comment #1 from Mark Wielaard --- I don't fully understand how you are building, and I cannot replicate, but it seems something goes wrong with readelf.c using the libdwP.h "internals" header. Does the following patch help? diff --git a/libdw/libdwP.h b/libdw/libdwP.h index 8b2f06fa5937..c1c84ed3567d 100644 --- a/libdw/libdwP.h +++ b/libdw/libdwP.h @@ -1153,8 +1153,7 @@ str_offsets_base_off (Dwarf *dbg, Dwarf_CU *cu) if (cu == NULL && dbg != NULL) { Dwarf_CU *first_cu; - if (INTUSE(dwarf_get_units) (dbg, NULL, &first_cu, - NULL, NULL, NULL, NULL) == 0) + if (dwarf_get_units (dbg, NULL, &first_cu, NULL, NULL, NULL, NULL) == 0) cu = first_cu; } -- You are receiving this mail because: You are on the CC list for the bug.
Re: [PATCH] Setter for Dwfl's offline_next_address
Hi Martin, On Fri, Mar 01, 2024 at 05:04:05PM -0300, Martin Rodriguez Reboredo wrote: > Added a new function dwfl_set_offline_next_addres which will set said > field from the Dwfl struct. This is a requirement for listing functions > from their addresses when using libdwfl offline, otherwise wrong symbols > are going to be returned. Could you give an example or testcase for this? Thanks, Mark
[Bug debuginfod/31103] periodically malloc_trim()
https://sourceware.org/bugzilla/show_bug.cgi?id=31103 Mark Wielaard changed: What|Removed |Added CC||mark at klomp dot org --- Comment #3 from Mark Wielaard --- Also note mallopt https://www.gnu.org/software/libc/manual/html_node/Malloc-Tunable-Parameters.html M_TRIM_THRESHOLD This is the minimum size (in bytes) of the top-most, releasable chunk that will trigger a system call in order to return memory to the system. If this parameter is not set, the default value is set as 128 KiB and the threshold is adjusted dynamically to suit the allocation patterns of the program. If the parameter is set, the dynamic adjustment is disabled and the value is set statically to the provided input. This parameter can also be set for the process at startup by setting the environment variable MALLOC_TRIM_THRESHOLD_ to the desired value. -- You are receiving this mail because: You are on the CC list for the bug.
Re: [PATCH] Setter for Dwfl's offline_next_address
Oh hi Mark! On 3/2/24 17:47, Mark Wielaard wrote: Hi Martin, On Fri, Mar 01, 2024 at 05:04:05PM -0300, Martin Rodriguez Reboredo wrote: Added a new function dwfl_set_offline_next_addres which will set said field from the Dwfl struct. This is a requirement for listing functions from their addresses when using libdwfl offline, otherwise wrong symbols are going to be returned. Could you give an example or testcase for this? This is intended for the Linux kernel perf tool so you might see it in action when I publish the changes. In regards to testing I thought that it was not needed due to the patch being a simple setter, but as requested I can think something in the lines of. int main (int argc, char **argv) { Dwfl *dwfl = dwfl_begin (&offline_callbacks); assert (dwfl != NULL); if (dwfl->offline_next_address != OFFLINE_REDZONE) { dwfl_end (dwfl); return 1; } int result = 0; dwfl_set_offline_next_address (dwfl, 0); if (dwfl->offline_next_address != 0) result = 1; dwfl_end (dwfl); return result; } But this will require libdwflP.h to be included, maybe if I add a getter too it'd remedy it. Thoughts? Thanks, Mark
[Bug general/31439] error: undefined reference to '__dwarf_get_units_internal'
https://sourceware.org/bugzilla/show_bug.cgi?id=31439 --- Comment #2 from rudi at heitbaum dot com --- (In reply to Mark Wielaard from comment #1) > I don't fully understand how you are building, and I cannot replicate, but > it seems something goes wrong with readelf.c using the libdwP.h "internals" > header. Does the following patch help? > > diff --git a/libdw/libdwP.h b/libdw/libdwP.h > index 8b2f06fa5937..c1c84ed3567d 100644 > --- a/libdw/libdwP.h > +++ b/libdw/libdwP.h > @@ -1153,8 +1153,7 @@ str_offsets_base_off (Dwarf *dbg, Dwarf_CU *cu) >if (cu == NULL && dbg != NULL) > { >Dwarf_CU *first_cu; > - if (INTUSE(dwarf_get_units) (dbg, NULL, &first_cu, > -NULL, NULL, NULL, NULL) == 0) > + if (dwarf_get_units (dbg, NULL, &first_cu, NULL, NULL, NULL, NULL) == > 0) > cu = first_cu; > } Hi mark, sorry for not sharing more yesterday, somehow I locked my account out on sourceware…. But I can confirm your patch does fix the build. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug general/31439] error: undefined reference to '__dwarf_get_units_internal'
https://sourceware.org/bugzilla/show_bug.cgi?id=31439 Mark Wielaard changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #3 from Mark Wielaard --- Thanks for testing. I don't know why I am unable to replicate or why none of our buildbots caught this. But it makes sense that an INTUSE used in readelf might cause issues. Fixed by: commit 7cf4586e5b429c0fa74d3ae73f49e6cda6660e93 Author: Mark Wielaard Date: Sun Mar 3 00:45:34 2024 +0100 libdw: Don't use INTUSE in libdwP.h str_offsets_base_off readelf.c cheats and include libdwP.h, which is an internal only header of libdw. It really shouldn't do that, but there are some internals that readelf currently needs. The str_offsets_base_off function used by readelf uses INTUSE when calling dwarf_get_units. This is a micro optimization useful inside libdw so a public function can be called directly, skipping a PLT call. This can cause issues linking readelf since it might not be able to call the internal function, since readelf.c isn't part of libdw itself. Just drop the INTUSE. * libdw/libdwP.h (str_offsets_base_off): Don't use INTUSE when calling dwarf_get_units. Signed-off-by: Mark Wielaard -- You are receiving this mail because: You are on the CC list for the bug.
Re: [PATCH] Setter for Dwfl's offline_next_address
Hi Martin, On Sat, Mar 02, 2024 at 07:43:38PM -0300, Martin Rodriguez Reboredo wrote: > On 3/2/24 17:47, Mark Wielaard wrote: > >On Fri, Mar 01, 2024 at 05:04:05PM -0300, Martin Rodriguez Reboredo wrote: > >>Added a new function dwfl_set_offline_next_addres which will set said > >>field from the Dwfl struct. This is a requirement for listing functions > >>from their addresses when using libdwfl offline, otherwise wrong symbols > >>are going to be returned. > > > >Could you give an example or testcase for this? > > This is intended for the Linux kernel perf tool so you might see it in > action when I publish the changes. In regards to testing I thought that > it was not needed due to the patch being a simple setter, but as > requested I can think something in the lines of. It would be interesting to see the perf tool patch. I don't understand the use case. So I assume perf currently does something which is wrong and with your patch calling this new dwfl_set_offline_next_addres it will do the right thing. That is what I was thinking of when asking for an example or testcase. I agree that on itself such a simple setter doesn't need a dedicated testcase. But maybe we can come up with a testcase given the right context. Cheers, Mark
Re: [PATCH] Setter for Dwfl's offline_next_address
On 3/2/24 21:05, Mark Wielaard wrote: Hi Martin, [...] It would be interesting to see the perf tool patch. I don't understand the use case. So I assume perf currently does something which is wrong and with your patch calling this new dwfl_set_offline_next_addres it will do the right thing. That is what I was thinking of when asking for an example or testcase. I agree that on itself such a simple setter doesn't need a dedicated testcase. But maybe we can come up with a testcase given the right context. Erm, I think I have a more clear example. When I use libdw to do something like addr2line with an ELF file I fail to get the address source line. Then I saw that eu-addr2line sets offline_next_address to zero. The following is the program I've used to see the source info of an address. int main(int argc, const char **argv) { if (argc != 3) return 1; Dwfl *dwfl = dwfl_begin(&offline_callbacks); if (!dwfl) return 1; dwfl_set_offline_next_address(dwfl, 0); if (!dwfl_report_offline(dwfl, "", argv[1], -1)) { dwfl_end(dwfl); return 1; } if (dwfl_report_end(dwfl, NULL, NULL)) { dwfl_end(dwfl); return 1; } char *endp = NULL; GElf_Addr addr = strtoumax(argv[2], &endp, 16); Dwfl_Module *mod = dwfl_addrmodule(dwfl, addr); int width = get_addr_width(mod); printf("0x%.*" PRIx64 "\n", width, addr); GElf_Sym s; GElf_Off off = 0; const char *name = dwfl_module_addrinfo(mod, addr, &off, &s, NULL, NULL, NULL); Dwfl_Line *line = dwfl_module_getsrc(mod, addr); if (!line) line = dwfl_getsrc(dwfl, addr); if (line) { int nline, column; const char *filename = dwfl_lineinfo(line, &addr, &nline, &column, NULL, NULL); printf("%s:%i,%i\n", filename, nline, column); } else { printf("??:0\n"); } dwfl_end(dwfl); return 0; } It could print the symbol name but that would've made the program much longer but I think that this should be clear now. Cheers, Mark