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

[Eduardo <erocha dot ssa at gmail dot com>]

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.

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
>