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:[email protected]] 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/tools-linking/attachments/20060621/02f7b558/attachment.html>
