From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29547 invoked by alias); 5 Jul 2010 19:35:52 -0000 Received: (qmail 29540 invoked by uid 22791); 5 Jul 2010 19:35:51 -0000 X-SWARE-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_20,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 05 Jul 2010 19:35:46 +0000 Received: from int-mx08.intmail.prod.int.phx2.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o65JZjT6002866 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 5 Jul 2010 15:35:45 -0400 Received: from [10.36.11.187] (vpn2-11-187.ams2.redhat.com [10.36.11.187]) by int-mx08.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o65JZiDq004764; Mon, 5 Jul 2010 15:35:44 -0400 Subject: Re: A 48 byte kernel module/cfi load mystery From: Mark Wielaard To: Roland McGrath Cc: systemtap@sourceware.org In-Reply-To: <20100702181914.DAD594AA6F@magilla.sf.frob.com> References: <1278069785.4626.29.camel@springer.wildebeest.org> <1278080076.4626.35.camel@springer.wildebeest.org> <20100702181914.DAD594AA6F@magilla.sf.frob.com> Content-Type: text/plain; charset="UTF-8" Date: Mon, 05 Jul 2010 19:35:00 -0000 Message-ID: <1278358543.4464.10.camel@springer.wildebeest.org> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2010-q3/txt/msg00020.txt.bz2 On Fri, 2010-07-02 at 11:19 -0700, Roland McGrath wrote: > Kernel modules are relocatable objects, so those addresses you see are as > placed by libdwfl. If you pass them to dwfl_module_relocate_address you > will get their section-relative offsets. Thanks for the explanation. In retrospect it is all so obvious :) > Let's take an example object: > > $ eu-readelf -S /usr/lib/debug/lib/modules/2.6.33.5-124.fc13.x86_64/kernel/fs/ext2/ext2.ko.debug > There are 44 section headers, starting at offset 0x245418: > > Section Headers: > [Nr] Name Type Addr Off Size ES Flags Lk Inf Al > [ 0] NULL 0000000000000000 00000000 00000000 0 0 0 0 > * [ 1] .note.gnu.build-id NOTE 0000000000000000 00000040 00000024 0 A 0 0 4 > * [ 2] .text NOBITS 0000000000000000 00000064 00009c8c 0 AX 0 0 4 > <...> > > Since the allocated section before it has size 0x24, that will be the > address where .text is placed. And the 0x48 on x86_64 was similar, but needed a bit more because of address alignements. > I've just changed eu-readelf (for the eventual 0.149) to print FDE > addresses like it does others from DWARF, so (without -N) it shows: > > [ 18] FDE length=52 cie=[ 0] > CIE_pointer: 0 > initial_location: .text+000000000000000000 > address_range: 0x5d > > I hope that helps avoid future confusion about this. Yes, that would have made the issue pretty clear. Thanks. I changed the systemtap translator to keep the .debug_frame FDE initial locations (the synthetic .debug_frame_hdr) on a per section basis, including a section load offset that the runtime unwinder uses to arrive at the correct relative address. For now, commit 4d83bd, only for the "magic sections", but will change to track them accurately for all sections covered. Cheers, Mark