1449588 – Can ltrace be built with backtrace support?

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1449588 - Can ltrace be built with backtrace support?

Summary: Can ltrace be built with backtrace support?

Keywords:
Status:	CLOSED ERRATA
Alias:	None
Product:	Red Hat Enterprise Linux 7
Classification:	Red Hat
Component:	ltrace
Sub Component:
Version:	7.2
Hardware:	Unspecified
OS:	Linux
Priority:	unspecified
Severity:	unspecified
Target Milestone:	rc
Target Release:	---
Assignee:	DJ Delorie
QA Contact:	Edjunior Barbosa Machado
Docs Contact:
URL:
Whiteboard:
Depends On:
Blocks:	1565233
TreeView+	depends on / blocked

Reported:	2017-05-10 10:24 UTC by Peter Edwards
Modified:	2018-10-30 10:16 UTC (History)
CC List:	10 users (show)
Fixed In Version:	ltrace-0.7.91-15.el7
Doc Type:	Enhancement
Doc Text:	Feature: Backtrace support Reason: Backtraces tell the user not just what function was called, but the context from which the call happened. Result: "ltrace -w 4 /bin/prog" (for example) will list the call stack for each traced call it displays, up to a maximum of 4.
Clone Of:
Environment:
Last Closed:	2018-10-30 10:16:43 UTC
Target Upstream Version:
Embargoed:

Attachments	(Terms of Use)

Links
System	ID	Private	Priority	Status	Summary	Last Updated
Red Hat Bugzilla	1498289	1	None	None	None	2021-01-20 06:05:38 UTC
Red Hat Product Errata	RHEA-2018:3133	0	None	None	None	2018-10-30 10:16:51 UTC

Internal Links: 1498289

Description Peter Edwards 2017-05-10 10:24:12 UTC

Description of problem:

When using ltrace-0.7.91-14.el7.x86_64 there is no backtrace option available:

> ltrace -h
...
  -w, --where=NR      print backtrace showing NR stack frames at most.

Version-Release number of selected component (if applicable):

ltrace-0.7.91-14.el7.x86_64

How reproducible:

Very.

Steps to Reproduce:
1. Run "ltrace -h"
2. Examine output for "-w" option

Actual results:

  No backtrace support.

Expected results:

  Backtrace support.

Additional info:

If the ltrace.spec file is built on a host with the libunwind-devel and libunwind packages installed then the RPMs built contain an ltrace executable with backtrace support.

So maybe in ltrace.spec, something like the following needs to be added:

BuildRequires: libunwind-devel
 
Also see:
  https://bugzilla.redhat.com/show_bug.cgi?id=1170296#c2

Thank you.

Comment 9 Mark Wielaard 2017-10-09 15:05:03 UTC

Note that upstream supports -w backtraces using elfutils libdw (I provided a patch for that some years ago):

commit dfefa9f057857735a073ea655f5cb34351032c8e
Author: Mark Wielaard <mjw>
Date:   Tue Jan 7 21:00:44 2014 +0100

    Add support for using elfutils as unwinder.
    
    This adds support for using elfutils as unwinder with -w. Since elfutils
    0.158 elfutils contains a simple unwinder interface that matches nicely
    on the ltrace backtrace support.
    
    The code reuses the libunwind infrastructure already in ltrace where
    possible (by defining HAVE_UNWINDER which is 1 if either libunwind or
    elfutils is used). It also reuses the ltrace proc_add_library callback
    to keep track of the ELF files mapped for the unwinder.
    
    The current implementation matches the output as if libunwind was used.
    But elfutils can also provide some more information since it can lookup
    the DWARF debuginfo. So if the source info of an address can be found
    through elfutils the backtrace will also include this as an additional
    output line per frame.

Comment 10 Carlos O'Donell 2017-10-09 15:10:57 UTC

(In reply to Mark Wielaard from comment #9)
> Note that upstream supports -w backtraces using elfutils libdw (I provided a
> patch for that some years ago):

I assume that means we can get the same functionality with just elfutils then? You don't say, but I assume this is what you mean.

Comment 11 Mark Wielaard 2017-10-09 15:32:29 UTC

(In reply to Carlos O'Donell from comment #10)
> (In reply to Mark Wielaard from comment #9)
> > Note that upstream supports -w backtraces using elfutils libdw (I provided a
> > patch for that some years ago):
> 
> I assume that means we can get the same functionality with just elfutils
> then? You don't say, but I assume this is what you mean.

Yes, that is what I meant for ltrace (on the architectures RHEL cares about).

There are some differences between the libunwind and elfutils libdw unwinder. The elfutils one is only for "out of process" unwinding (core files or other processes through ptrace), libunwind also contains an in-process unwinder. And libunwind supports a couple of architectures that elfutils libdw doesn't. But elfutils does support all main architectures supported by RHEL.

Comment 15 errata-xmlrpc 2018-10-30 10:16:43 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2018:3133

Note You need to log in before you can comment on or make changes to this bug.