Re: How to access an applications ELF program header and ELFsection header at runtime

[Petr Baudis <pasky at suse dot cz>]

  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
over time - the heap will grow with brk()/sbrk(), new objects will be
linked in with dlopen(), mappings will come and go by mmap(), mremap()
and munmap()... and that's all I can think of, there might be more but
if you cover for these calls, you should probably cover most of the
cases...

  ...except it might be impossible to hijack mmap() calls inside glibc
(e.g. in malloc() ;-).  I would say you have three reasonable (and
several unreasonable) choices: ptrace()ing your application to pick out
offending syscalls, patching the kernel to notify you about mapping
changes, or restricting your project to indeed support only static
storage synchronization and disallow dlopen().

-- 
				Petr "Pasky" Baudis
A lot of people have my books on their bookshelves.
That's the problem, they need to read them. -- Don Knuth