dmh cannot find gblic mapped in memory because glibc name contains no dash

[gordon-quad]

Environment

Sun  5 Dec 19:29:12 GMT 2021
radare2 5.3.1 0 @ linux-x86-64 git.5.3.1
commit: 5.3.1 build: 2021-12-05__18:49:14
Linux x86_64

Description

Seems that r_resolve_main_arena function relies upon fact that libc filename contains version number with dash in the middle, which is not true for some distros (e.g. Gentoo).
https://github.com/radareorg/radare2/blob/master/libr/core/linux_heap_glibc.c#L414

Test

$ r2 -d /bin/ls
Process with PID 21229 started...
= attach 21229 21229
bin.baddr 0x55a87bb72000
Using 0x55a87bb72000
asm.bits 64
Continue until 0x55a87bb783e0 using 1 bpsize
hit breakpoint at: 0x55a87bb783e0
 -- (gdb) ^D
[0x55a87bb783e0]> db main
[0x55a87bb783e0]> dc
hit breakpoint at: 0x55a87bb76720
[0x55a87bb76720]> dmh
Warning: Can't find glibc mapped in memory (see dm)
[0x55a87bb76720]> dm~libc:0[9]
/lib64/libc.so.6

[trufae]

Press the pencil icon and make a pr with the fix if you know where is the issue

[gordon-quad]

@trufae I know where the issue is and I would love to fix it, but I'm not really sure how should I approach it, since if I just remove the dash it may match with any library that starts with "libc", and checking for '-' or '.' sounds a bit too ad-hoc of a solution. Any clue if it is possible to determine where libc is in some other way? Or add some way of specifying which mapping is the libc to have at least a workaround for "weirder" distros?

[trufae]

The current approach is already fuzzy iirc, as long as the library is linked to the binary we can get the name from rbin. But this will work only on local debugging, which is the main use case i guess.

But for an easier solution your proposal lgtm if added as fallback when the libc- cant be found.