From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 29 14:13:03 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3BA71106566C for ; Wed, 29 Sep 2010 14:13:03 +0000 (UTC) (envelope-from kadupl@wp.pl) Received: from mx4.wp.pl (mx4.wp.pl [212.77.101.8]) by mx1.freebsd.org (Postfix) with ESMTP id BD3118FC1D for ; Wed, 29 Sep 2010 14:13:02 +0000 (UTC) Received: (wp-smtpd smtp.wp.pl 18729 invoked from network); 29 Sep 2010 16:13:01 +0200 Received: from out.poczta.wp.pl (HELO localhost) ([212.77.101.240]) (envelope-sender ) by smtp.wp.pl (WP-SMTPD) with SMTP for ; 29 Sep 2010 16:13:01 +0200 Date: Wed, 29 Sep 2010 16:13:01 +0200 From: PL To: Andriy Gapon Message-ID: <4ca3496d8ce8b3.74842248@wp.pl> References: <4ca2f64ee66683.99262397@wp.pl> <4CA2FFAE.6030906@icyb.net.ua> In-reply-to: <4ca2f64ee66683.99262397@wp.pl> <4CA2FFAE.6030906@icyb.net.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 8bit Content-Disposition: inline X-Mailer: Interfejs WWW nowej poczty Wirtualnej Polski X-User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.10) Gecko/20100916 Firefox/3.6.10 Organization: Poznaj Poczte WP http://poczta.wp.pl/info-start.html X-WP-IP: 213.17.239.108 X-WP-AV: skaner antywirusowy poczty Wirtualnej Polski S. A. X-WP-SPAM: NO 0000000 [UTME] Cc: freebsd-hackers Subject: Re: question regarding link_elf.c X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 14:13:03 -0000 Dnia 29-09-2010 o godz. 10:58 Andriy Gapon napisał(a): > on 29/09/2010 11:18 PL said the following: > > Hi everyone, > > I'm not quiet sure if it is proper place to ask the question I have. If > > not, please > > direct me to the correct place I should post questions like: > > > > Im working on some modifications around link_elf.c. According to elf(5) > > man pages, > > Elf_Shdr structure contains field called 'sh_addr', containing the > > address at > > which first byte of a section shall reside in the memory image. I am > > particularily > > interested in '.text' and '.data' sections. After link_elf_load_file() > > loads the > > file into a memory, we have linker_file structure filled in, including > > 'address' > > field. Now, assuming 'lf' being linker_file_t, already filled in by the > > loading > > routine, 'text_sh' being 'Elf_Shdr' for text section, and 'data_sh' > > being 'Elf_Shdr' > > for data section: > > - lf->address + text_sh.sh_addr really points to the beginning of a > > '.text' section > > in memory, however.. > > > > - lf->address + data_sh.sh_addr does not point to the valid location of > > '.data' section > > in memory. > > > > Sorry if my question is stupid, but im wondering why it is so ? I guess > > it has something > > to do with virtual memory mapping (?). > > Perhaps the reason is simpler, like a bug in your code :-) > You can do 'readelf -a' on a module that you load and check attributes > of .data > section and then compare with data_sh that you get at run-time. > > -- > Andriy Gapon > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" It seems like it is not a problem in my own code, since readelf -S on a elf file gives me the same results as my debug messages. I've created an empty module, to simplify debugging. Both my code, and readelf says, that '.text' section address is 0x3e0, and its size is 7 bytes. Adding 0x3e0 to lf->address points to a valid location. '.data' is supposed to be at 0x1424 (again, both my code and readelf returns the same thing), but the actual data starts at lf->address + 0x3e7. How do I know ? I've added global initialized string variable in empty test module, and Im looking at the memory to determine it's location. I'm not sure what is wrong then.