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] |
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
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] |