From owner-freebsd-standards@freebsd.org Wed Oct 28 06:17:31 2015 Return-Path: Delivered-To: freebsd-standards@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EE6CEA20845 for ; Wed, 28 Oct 2015 06:17:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C13BD179B for ; Wed, 28 Oct 2015 06:17:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t9S6HVaV021945 for ; Wed, 28 Oct 2015 06:17:31 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-standards@FreeBSD.org Subject: [Bug 204084] libdwarf does not handle SHT_REL relocations properly Date: Wed, 28 Oct 2015 06:17:31 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: standards X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: hackagadget@gmail.com X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-standards@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2015 06:17:32 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204084 Bug ID: 204084 Summary: libdwarf does not handle SHT_REL relocations properly Product: Base System Version: 11.0-CURRENT Hardware: arm OS: Any Status: New Severity: Affects Only Me Priority: --- Component: standards Assignee: freebsd-standards@FreeBSD.org Reporter: hackagadget@gmail.com Created attachment 162523 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=162523&action=edit Sample object file with bogus .SUNW_ctf due to SHT_REL mishandling When using dtrace on ARM and I tracked it down to what I think is an issue in libdwarf and how it is handling relocations. >From what I've been able to tell from reading various specifications and other documents, relocations of the DWARF sections are supposed to be handled as follows: 1. Given the following: P is the address we want to do relocations on S is the value of the symbol referenced in the relocation entry A is the addendum in the relocation entry 2. For SHT_RELA type, we need to take S, add A, then store the resulting value at the location P 3. For SHT_REL type, we need to take the value at the location P, add S, then store the resulting value at the location P >From what I was able to read in the libdwarf code (contrib/elftoolchain/libdwarf/libdwarf_elf_init.c), it looks like SHT_RELA type is handled correctly. However, for SHT_REL type, there seems to be a missing step. It looks like it is just taking S and storing that at the location P, which ends up clobbering the value that was already at the location P. This ends up being a disaster for ctfconvert, as you end up with very few to no actual symbols in that binary able to be used in probe statements. See the attached arc4random.o file. This was built with the clang 3.5.1 for ARM. You should be able to use ctfdump on it to see the bogus .SUNW_ctf section data generated by ctfconvert as the code currently exists (with the flawed REL relocation handling.) -- You are receiving this mail because: You are the assignee for the bug.