How to access an applications ELF program header and ELF section header at runtime

Bharath Ramesh bramesh@vt.edu
Tue Jan 5 22:51:00 GMT 2010


On Tue, Jan 05, 2010 at 12:56:30AM +0100, Petr Baudis wrote:
>   Hi!
> 
> On Mon, Jan 04, 2010 at 04:03:31PM -0500, Bharath Ramesh wrote:
> > On Fri, Oct 23, 2009 at 11:02:55AM -0400, Carlos O'Donell wrote:
> > > On Thu, Oct 22, 2009 at 4:49 PM, Bharath Ramesh <bramesh@vt.edu> wrote:
> > > > I am trying to play around with the symbols __data_start and __bss_start
> > > > to access the location of the .data and .bss section. Is there any way I
> > > > need to typecast these symbols so that I can get the information from
> > > > these symbols.
> > > 
> > > extern const char __symbol __attribute__((weak));
> > > #define symbol ((unsigned long)&__symbol)
> > > 
> > 
> > As mentioned in earlier emails to this thread [1] I need to access the
> > .data and .bss sections of an application. I need to access this from
> > the constructor of my shared library. I am not of the reason, but I am
> > an unable to get access to __data_start. It always has a value of NULL
> > address to it. I am able to get valid value for _edata, __bss_start and
> > _end. When I use nm to list the symbols of the application __data_start
> > does exist with an offset, but __data_start symbol for the shared
> > library doesnt have any offset. Is there something I am missing, is
> > there any way I can make sure that I get the valid address for these
> > symbols from the constructor of the shared library.
> 
>   I think these symbols correspond just to the sections in your local
> ELF object, not in the main program; furthermore, there can be multiple
> such sections in the ELF object, and all sorts of other hairy issues.
> 
>   I think you are seriously best off just parsing /proc/self/maps, which
> will give you up-to-date and complete information; you will probably
> want to sync all PROT_WRITE mappings. Note that the mappings can change

I am trying to understand the format of /proc/self/maps. From looking at
the map and the section headers from objdump of the application I have
some understanding. It would be great if I someone can correct me if I
am wrong.

00400000-00401000 r-xp 00000000 08:02 5669441	/home/bharath/Research/code/test/globals/maps
00600000-00601000 r--p 00000000 08:02 5669441	/home/bharath/Research/code/test/globals/maps
00601000-00602000 rw-p 00001000 08:02 5669441	/home/bharath/Research/code/test/globals/maps
01e66000-01e88000 rw-p 00000000 00:00 0		[heap]
<snip>

My understanding is as follows:

1) Line 1 would be the mapping for the .text section of the application
since it is read-only and executable.
2) Line 2 would be something to .got and other sections as it is
read-only.
3) Line 3 corresponds to .data & .bss.

Am I safe in assuming that the first line in /proc/self/maps which has
write permissions would correspond to .data and .bss. Is there any other
mapping that I would have to worry about that occurs before [heap] which
might correspond to any one of the .data and .bss sections. I really
appreciate the time that you are taking out to answer my questions.

Regards,

Bharath
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 2245 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-help/attachments/20100105/53668862/attachment.bin>


More information about the Libc-help mailing list