Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 29 Sep 2010 11:58:22 +0300
From:      Andriy Gapon <avg@icyb.net.ua>
To:        PL <kadupl@wp.pl>
Cc:        freebsd-hackers@freebsd.org
Subject:   Re: question regarding link_elf.c
Message-ID:  <4CA2FFAE.6030906@icyb.net.ua>
In-Reply-To: <4ca2f64ee66683.99262397@wp.pl>
References:  <4ca2f64ee66683.99262397@wp.pl>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4CA2FFAE.6030906>