From owner-freebsd-amd64@FreeBSD.ORG Mon Jun 21 15:43:52 2010 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12B141065672; Mon, 21 Jun 2010 15:43:52 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id D9C8C8FC14; Mon, 21 Jun 2010 15:43:51 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 8D2D846B5C; Mon, 21 Jun 2010 11:43:51 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id A1DC68A04F; Mon, 21 Jun 2010 11:43:50 -0400 (EDT) From: John Baldwin To: Andriy Gapon Date: Mon, 21 Jun 2010 11:43:26 -0400 User-Agent: KMail/1.12.1 (FreeBSD/7.3-CBSD-20100217; KDE/4.3.1; amd64; ; ) References: <4C1F798C.7010204@freebsd.org> In-Reply-To: <4C1F798C.7010204@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201006211143.26459.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 21 Jun 2010 11:43:50 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-hackers@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: amd64 kernel modules: mapping sections to addresses X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 15:43:52 -0000 On Monday 21 June 2010 10:39:08 am Andriy Gapon wrote: > > I've noticed that on amd64 addresses (sh_addr) of all sections in a kernel module > are zeros. > This is unlike kernel itself and i386 modules. > > Kernel linker maps SHT_PROGBITS and SHT_NOBITS sections sequentially starting at a > certain base address and taking into account their sizes and alignment requirements. > > On the other hand, kgdb calculates section address as module base address plus > sh_addr of the section. Which puts all sections, e.g. .text, .data, .bss, at the > same address. This is correct only for .text which is normally the first section > described in a header. > > DTrace situation is even worse, because don't even take into account module base > address, not speaking of section relative addresses. > > Perhaps we should put some sh_addr values into amd64 kernel modules that would > match calculations done in link_elf_load_file. > Or should we replicate logic from link_elf_load_file in all places that need to > map loaded module's sections to load addresses? > > What do you think? > Thanks! > > P.S. > As I understand CTF data includes a symbol table. > What kind of symbol addresses is used there? Are they relative within a > corresponding section? Or something else? np@ has a patch to gdb to fix this for kgdb. I haven't committed it as it patched gdb internals and wasn't in a kgdb-specific place, but I'm not sure of a better way to fix kgdb. -- John Baldwin