This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


> -----Original Message-----
> From: Eduardo [mailto:erocha.ssa@gmail.com]
> Sent: Wednesday, August 19, 2009 12:15 PM
> To: Bharath Ramesh
> Cc: Carlos O'Donell; libc-help@sourceware.org
> Subject: Re: How to access an applications ELF program header and ELF
> section header at runtime
> 
> Hi Bharath,
> 
> I think it's ok to use the symbols __start_data, __start_bss, etc (or
> even dlopen the code itself) in a research project. If I were you,
> though, I would create a level of abstraction in order to guarantee
> that in the future I could change easily the way I get this
> information.

Would dlopen work on a binary, isn't that to be used only with dynamic
libraries. My plan is to have a level of abstraction so that in the future I
can modify this if required. Thanks for the help.

Regards,

Bharath

> 
> Best regards,
> Eduardo
> 
> On Wed, Aug 19, 2009 at 10:58 AM, Bharath Ramesh<bramesh@vt.edu> wrote:
> >> -----Original Message-----
> >> From: patofiero@gmail.com [mailto:patofiero@gmail.com] On Behalf Of
> >> Carlos O'Donell
> >> Sent: Wednesday, August 19, 2009 11:50 AM
> >> To: Bharath Ramesh
> >> Cc: Eduardo; libc-help@sourceware.org
> >> Subject: Re: How to access an applications ELF program header and
> ELF
> >> section header at runtime
> >>
> >> On Wed, Aug 19, 2009 at 9:38 AM, Bharath Ramesh<bramesh@vt.edu>
> wrote:
> >> > Given this premise that these symbols are part of the linker
> script
> >> and the
> >> > fact that the existence of .data and .bss section is not
> guaranteed,
> >> is
> >> > there a consistent way of locating the region/section where all
> the
> >> global
> >> > data of an application is stored in the applications address space
> >> and the
> >> > length of this region/section.
> >>
> >> There is no consistent way of locating the region/section where all
> >> the global data of an application is stored.
> >>
> >> You can dlopen yourself and lookup a single symbol.
> >>
> >> What problem are you actually trying to solve?
> >
> > In my research project I am trying to provide shared memory semantics
> over
> > distributed memory. This requires that the global data of the
> application be
> > consistent across all physical nodes of the cluster. I can make this
> > consistent but I need to know where the application's global data is
> stored
> > and the size of this region/section so that I can keep it consistent
> during
> > the execution of the application on the cluster.
> >
> > Regards,
> >
> > Bharath
> >

Attachment: smime.p7s
Description: S/MIME cryptographic signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]