I can give you some advice - it will be up to the Sun folks to give the definitive answer.
The rtld_db interface was designed for debuggers to use to report on the objects that the run-time linker (ld.so.1) has loaded into memory, not on all mappings that exist. If your program is unmapping objects and placing new objects in their place - then ld.so.1 doesn't know about that and hence rtld_db won't be able to report on it. This also implies that if you later 'dlopen()' a library in your program the symbols for your new object will not be available because ld.so.1 doesn't know about it. Possibly ld.so.1 would even bind you to non existent interfaces because you have unmmapped a library it thought was under its control =0 If you want rtld_db to understand the object loaded I think you need to have it loaded (or unloaded) via the standard ld.so.1 interfaces - these would be 'dlopen()/dlclose()'. Good Luck, _Mike_ On 6/21/06, Ovidiu Nastai <onastai at trigence.com> wrote: > > > > Hi tools-linking, > please somebody spend some time on my request. Bart Smaalders pointed me to > you. see below the details. > Regards, > ovi > sw eng > Trigence Corp. > > > -----Original Message----- > From: Ovidiu Nastai > Sent: Mon 6/19/2006 2:43 PM > To: Bart Smaalders > Subject: RE: rtld secretive work... > > > > > -----Original Message----- > From: Bart Smaalders [mailto:bart.smaalders at Sun.COM] > Sent: Mon 6/19/2006 12:28 PM > To: Ovidiu Nastai > Subject: Re: rtld secretive work... > > Ovidiu Nastai wrote: > > Bart, > > something happened while trying to send this message, I am retrying it. > > you might get it twice. > > > > 1. what is the _rd_reset64 doing behind-the-scenes? > > I am unmapping .data/.bss/.text of an existing proc, and mapping > > .data/.bss/.text of a new executable, then jump to the entry point of > > the new mapped code. I can see the rd_loadobj_iter calls map_iter > > (inside which file_info_new is populatind a data member I need) only for > > the "old" mappings (i.e. the ones before the unmap/map). consequently, > > pmap will not display mapping names resolved to meaningful strings, but > > rather inode numbers. > > 2. can I do anything (i.e. resetting a status flag of the > > rd_agent_t/ps_prochandle objects), so that _rd_reset64 will cause > > map_iter to be called for every entry existing in /proc/pid/map binary > > file? my end goal it to have file_info_new resolve each entry read from > > the /proc/pid/map file (see Pupdate_maps). > > > > please spread some light. > > > > Regards, > > ovi > > > > Hmmm.... (I think I just sent you an empty reply by mistake; > shortcuts are tricky :-)). > > Can you describe the actors (which processes are doing what > to whom)? > > Thanks - > > -0 Bart > > > -- > Bart Smaalders Solaris Kernel Performance > barts at cyber.eng.sun.com http://blogs.sun.com/barts > > > Bart, > please see below: > I have my own app, let's call it myApp, having loaded some in-house libs, > amongst the OS' ones. so that myApp is running, and, at some point, after > some init work, myApp unmaps its-self (mainly the .text segment), maps in > the .text segment of another app (i.e. /bin/bash), and jumps to the new > entry point. of course, the unmap/map work is done in one of the in-house > shared libs made specifically for this puspose. > so, the "new" myApp, still has the same pid (let's call it myAppPid) as > before the unmap/map step. and the "old" shared objects, in addition to the > new ones brought by way of the new .text segment, as well. > then, I run "pmap myAppPid", and see that the new mappings created when the > latest .text segment is being run, are not resolved as the "old" (i.e. the > initial myApp's) ones are. for instance, I do get : > ... > 00010000 648K r-x-- /usr/bin/bash > 000C0000 80K rwx-- /usr/bin/bash > 000D4000 8K rwx-- [ heap ] > 000D6000 136K rwx-- [ heap ] > F0000000 176K r-x-- dev:136,8 ino:19079 > F003C000 8K rwx-- dev:136,8 ino:19079 > ... > , as opposed to the expected : > ... > 00010000 648K r-x-- /usr/bin/bash > 000C0000 80K rwx-- /usr/bin/bash > 000D4000 248K rwx-- [ heap ] > FF100000 848K r-x-- /lib/libc.so.1 > FF1E4000 32K rwx-- /lib/libc.so.1 > ... > for the "pmap bashPid" (bashPid comes from a ps, for instance). I walked > the code (spark assembly) with mdb, and realized that the rd_loadobj_iter > calls map_iter (inside which file_info_new is populatind a data member I > need) only for the "old" mappings (i.e. the ones before the unmap/map). > myApp behaves ok, however, I would like to have pmap displaying the object's > path (it looks that if I could lure rd_loadobj_iter to call map_iter for > every mapping existing in /proc/myAppPid/map file, which, by-the-way is > updated correctly, it might do it) resolved to a path name and not a inod. > I was thinking that _rd_reset64 has something to do with the way > rd_loadobj_iter calls map_iter. if there is some "caching" going on, how > could I flush/invalidate it, and get a rd_agent which, eventually, would > cause map_iter to get invoked with a rd_loadobj_t *lop for EACH mapping > present in the /proc/myAppPid/map file. > if _rd_reset64 looks for a "status/state" flag, and behaves discriminatory, > please point me to, I might try to clean it up, so that after my > "un-orthodox" unmap/map step, I start with a state that does not misslead > the rtld lib. > > tnx, > ovi > > _______________________________________________ > tools-linking mailing list > tools-linking at opensolaris.org > > -- Michael Walker mwalker at fins.com
