[Bug general/31439] error: undefined reference to '__dwarf_get_units_internal'

2024-03-02 Thread mark at klomp dot org
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

2024-03-02 Thread Mark Wielaard
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()

2024-03-02 Thread mark at klomp dot org
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

2024-03-02 Thread Martin Rodriguez Reboredo

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'

2024-03-02 Thread rudi at heitbaum dot com
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'

2024-03-02 Thread mark at klomp dot org
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

2024-03-02 Thread Mark Wielaard
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

2024-03-02 Thread Martin Rodriguez Reboredo

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