From owner-freebsd-amd64@FreeBSD.ORG  Mon Jun 21 14:39:12 2010
Return-Path: <owner-freebsd-amd64@FreeBSD.ORG>
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 9AAFA106564A;
	Mon, 21 Jun 2010 14:39:12 +0000 (UTC) (envelope-from avg@freebsd.org)
Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140])
	by mx1.freebsd.org (Postfix) with ESMTP id 442D28FC0A;
	Mon, 21 Jun 2010 14:39:10 +0000 (UTC)
Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua
	[212.40.38.101])
	by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA23978;
	Mon, 21 Jun 2010 17:39:09 +0300 (EEST)
	(envelope-from avg@freebsd.org)
Message-ID: <4C1F798C.7010204@freebsd.org>
Date: Mon, 21 Jun 2010 17:39:08 +0300
From: Andriy Gapon <avg@freebsd.org>
User-Agent: Thunderbird 2.0.0.24 (X11/20100517)
MIME-Version: 1.0
To: freebsd-hackers@freebsd.org, freebsd-amd64@freebsd.org
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Mon, 21 Jun 2010 16:26:33 +0000
Cc: 
Subject: 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 <freebsd-amd64.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-amd64>,
	<mailto:freebsd-amd64-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-amd64>
List-Post: <mailto:freebsd-amd64@freebsd.org>
List-Help: <mailto:freebsd-amd64-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-amd64>,
	<mailto:freebsd-amd64-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Jun 2010 14:39:12 -0000


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?

-- 
Andriy Gapon