Does glibc support remote process backtracing

Does glibc support remote process backtracing

[Abhijit Ray Chaudhury]

[-- Attachment #1: Type: text/plain, Size: 230 bytes --]

Hi,
Libunwind supports remote process backtracing through libunwind-ptrace (
https://www.nongnu.org/libunwind/man/libunwind-ptrace(3).html ). Does glibc
also support remote process backtracing ?

Thanking you in advance,
-Abhijit

Re: Does glibc support remote process backtracing

[Florian Weimer]

* Abhijit Ray Chaudhury via Libc-help:

> Hi,
> Libunwind supports remote process backtracing through libunwind-ptrace (
> https://www.nongnu.org/libunwind/man/libunwind-ptrace(3).html ). Does glibc
> also support remote process backtracing ?

For current architectures, glibc does not supply an implementation of
stack unwinding/backtrace generatio.  We use libgcc_s for that (via the
unwind-link facility in glibc).  There's no remote backtracing support
in libgcc_s.

There's a remote backtrace implementation in elfutils, which probably
has a greater affinity with the GNU toolchain on Linux (compared to
libunwind).

Thanks,
Florian

Re: Does glibc support remote process backtracing

[Abhijit Ray Chaudhury]

[-- Attachment #1: Type: text/plain, Size: 1251 bytes --]

Hi Florian,

Thanks a lot for replying. I need to do remote stack tracing , for which I
am using libunwind-ptrace . The problem is it does not work on VDSOs . It
treats VDSO memory mapping entry in /proc/<pid>/maps as a file and tries to
open it and subsequently fails.
I tried mailing in libunwind-dev, but it seemed dormant .

I need a library which works on both arm and x86_64 , do you think elfutils
would be a good option ?

Thanks in Advance,
-Abhijit

On Mon, Nov 27, 2023 at 2:50 PM Florian Weimer <fweimer@redhat.com> wrote:

> * Abhijit Ray Chaudhury via Libc-help:
>
> > Hi,
> > Libunwind supports remote process backtracing through libunwind-ptrace (
> > https://www.nongnu.org/libunwind/man/libunwind-ptrace(3).html ). Does
> glibc
> > also support remote process backtracing ?
>
> For current architectures, glibc does not supply an implementation of
> stack unwinding/backtrace generatio.  We use libgcc_s for that (via the
> unwind-link facility in glibc).  There's no remote backtracing support
> in libgcc_s.
>
> There's a remote backtrace implementation in elfutils, which probably
> has a greater affinity with the GNU toolchain on Linux (compared to
> libunwind).
>
> Thanks,
> Florian
>
>

Re: Does glibc support remote process backtracing

[Florian Weimer]

* Abhijit Ray Chaudhury:

> Hi Florian,
>
> Thanks a lot for replying. I need to do remote stack tracing , for which I am using libunwind-ptrace
> . The problem is it does not work on VDSOs . It treats VDSO memory mapping entry in
> /proc/<pid>/maps as a file and tries to open it and subsequently fails.
> I tried mailing in libunwind-dev, but it seemed dormant .
>
> I need a library which works on both arm and x86_64 , do you think elfutils would be a good option
> ?

The AArch64 vDSO did not have accurate unwinding information in the
past.  We've got a Fedora bug for this:

  kernel: vDSO lacks unwind information on aarch64
  <https://bugzilla.redhat.com/show_bug.cgi?id=2044483>

I don't know if this has been fixed since then.

Thanks,
Florian

Re: Does glibc support remote process backtracing

[Szabolcs Nagy]

The 12/11/2023 10:14, Florian Weimer via Libc-help wrote:
> * Abhijit Ray Chaudhury:
> > Hi Florian,
> >
> > Thanks a lot for replying. I need to do remote stack tracing , for which I am using libunwind-ptrace
> > . The problem is it does not work on VDSOs . It treats VDSO memory mapping entry in
> > /proc/<pid>/maps as a file and tries to open it and subsequently fails.
> > I tried mailing in libunwind-dev, but it seemed dormant .
> >
> > I need a library which works on both arm and x86_64 , do you think elfutils would be a good option
> > ?
> 
> The AArch64 vDSO did not have accurate unwinding information in the
> past.  We've got a Fedora bug for this:
> 
>   kernel: vDSO lacks unwind information on aarch64
>   <https://bugzilla.redhat.com/show_bug.cgi?id=2044483>
> 
> I don't know if this has been fixed since then.

i believe it is not fixed.