Hi I am working on this program(P1) that loads another program(P2, "Hello World") and passes control to it to execute. How this works is all the P2 program headers(PT_LOAD) are mapped into memory, then the interpreter for P2 is loaded into memory, the appropriate auxv entries modified to tell the interpeter its base address and P2''s entry point and then do a jmp to the interpreter''s entry address. My program is crashing at that point(after doing a jmp into interpreter). This code actually worked on Sol 8 and I am trying to do the same on Sol Exp but without much success. P2 is wellformed and runs correctly when run on its own[./P2 or /lib/ld.so ./P2]. How can I trace whats going on in the runtime linker ? I tried using pid$target:ld.so:: but that doesn''t work. Any suggestions would be appreciated. Thanks Naveen ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs
Naveen Kumar wrote:> Hi > I am working on this program(P1) that loads another > program(P2, "Hello World") and passes control to it to > execute. How this works is all the P2 program > headers(PT_LOAD) are mapped into memory, then the > interpreter for P2 is loaded into memory, the > appropriate auxv entries modified to tell the > interpeter its base address and P2''s entry point and > then do a jmp to the interpreter''s entry address. My > program is crashing at that point(after doing a jmp > into interpreter). This code actually worked on Sol 8 > and I am trying to do the same on Sol Exp but without > much success. P2 is wellformed and runs correctly when > run on its own[./P2 or /lib/ld.so ./P2]. How can I > trace whats going on in the runtime linker ? I tried > using pid$target:ld.so:: but that doesn''t work. Any > suggestions would be appreciated.If P1 is running, then you have a runtime linker (L1) associated with the process. dtrace knows about the process instance of the runtime linker, and syntax such as "pid$target:ld.so:" will alow you some visibility. If you load another program (P2) and another runtime linker (L2), dtrace isn''t going to know about these. These are just memory mappings - they could be anything. I don''t believe there''s any way to tell dtrace - "hey, here''s new runtime linker, it''s mapped at this address". What are you trying to do besides circumvent an exec()? -- Rod.
On Thu, Jul 14, 2005 at 10:48:49AM -0700, Naveen Kumar wrote:> Hi > I am working on this program(P1) that loads another > program(P2, "Hello World") and passes control to it to > execute. How this works is all the P2 program > headers(PT_LOAD) are mapped into memory, then the > interpreter for P2 is loaded into memory, the > appropriate auxv entries modified to tell the > interpeter its base address and P2''s entry point and > then do a jmp to the interpreter''s entry address. My > program is crashing at that point(after doing a jmp > into interpreter). This code actually worked on Sol 8 > and I am trying to do the same on Sol Exp but without > much success. P2 is wellformed and runs correctly when > run on its own[./P2 or /lib/ld.so ./P2]. How can I > trace whats going on in the runtime linker ? I tried > using pid$target:ld.so:: but that doesn''t work. Any > suggestions would be appreciated.You probably want the -xevaltime= option; that controls when dtrace stops the process to inject the userland probes. The possible values are: exec At process creation time, before the runtime linker gets control. preinit (the default) After all of the non-lazy libraries have been loaded into the process, but before any ''.init'' sections have been run. postinit after shared objects have been initialized, but before _startup() is called. main at the first instruction of main() It may help to add "-xevaltime=exec", if you want to look at runtime linker activity during process setup. However, I''m not sure how well having your own custom interpreter will work; the userland tracing stuff in dtrace is heavily dependent upon rtld_db(3EXT) for its functioning. Out of curiousity, why isn''t using exec(2) sufficient? Cheers, - jonathan -- Jonathan Adams, Solaris Kernel Development
It is to be used in a port of valgrind(http://www.valgrind.org) to solaris. valgrind(P1) loads its stage2(P2) which then loads an executable for instrumentation. I was having problems in P1 loading and passing control to P2. I figured that out. It was some area of memory not being zeroed out. I will try this option though. Thanks Naveen> You probably want the -xevaltime= option; that > controls when dtrace stops > the process to inject the userland probes. The > possible values are: > > exec At process creation time, before the runtime > linker > gets control. > > preinit (the default) After all of the non-lazy > libraries have > been loaded into the process, but before any > ''.init'' > sections have been run. > > postinit after shared objects have been > initialized, but before > _startup() is called. > > main at the first instruction of main() > > It may help to add "-xevaltime=exec", if you want to > look at runtime linker > activity during process setup. > > However, I''m not sure how well having your own > custom interpreter will work; > the userland tracing stuff in dtrace is heavily > dependent upon rtld_db(3EXT) > for its functioning. Out of curiousity, why isn''t > using exec(2) sufficient? > > Cheers, > - jonathan > > > -- > Jonathan Adams, Solaris Kernel Development >____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs