Thanks, Tirthankar
Frank Hofmann wrote: > On Fri, 13 Jul 2007, Tirthankar wrote: > >> Hi Frank, >> >> CR 6226326 has been put back to s10u3 also. It doesnt display the >> parameters. My understanding is it essentially makes ::findstack work >> on an AMD64 core. > > > It was put back into onnv together with the save_args support, for > which I cannot find the bugID right now; the latter is what matters, > it's _NOT_ backported. Only opensolaris/onnv. > Ok I understand. Will try to find the CR >> >> The blog is a good pointer to find the parameters, but I would be >> more happy if mdb could displaythe parametes like it does for sparc >> cores. Makes a debuggers life much easier :) > > > That's why you have the feature in OpenSolaris - to make your life > easier ... > Unfortunately our products primary platform is S10 sokind of stuck with that. > Btw, it's not _that_ much easier on SPARC. You don't know whether your > argument registers have been re-used. On the (good) chance that they > have not, you might get away with not having to look at the > disassembly. But then, that's not _always_ the case. > Ya I agree with you. Justthat I am more familiar with spark debugging :) > FrankH. > >> >> Thanks, >> Tirthankar >> >> >> >> Frank Hofmann wrote: >> >>> On Sun, 8 Jul 2007, Tirthankar wrote: >>> >>>> Hi, >>>> >>>> I am trying to debug a core from a AMD64 machine running S10u3. >>>> >>>> MDB is unable to show any parameters in the stack backtrace >>> >>> >>> >>> Yes, stacktraces with arguments shown were only integrated in >>> onnv/OpenSolaris via: >>> >>> 6226326 Need to improve stack tracing on x86 >>> >>> This works via compiler support - onnv/OpenSolaris is compiled in >>> such a way that the generated assembly code stores function >>> arguments on the stack as well as in the (ABI-mandated) registers. >>> This way, mdb can show function arguments in stacktraces. >>> >>> Solaris 10 doesn't do that. You'll need to do a manual heuristic. >>> ACT is able to perform some of this work but it's not perfect. The >>> whole shebang of how argument passing on AMD64 works and which >>> heuristics are needed so that arguments can be reconstructed from >>> the code flow is explained in: >>> >>> http://opensolaris.org/os/community/documentation/doc_index/dev/ >>> >>> See "Crashdump Analysis". The file is: >>> >>> http://opensolaris.org/os/community/documentation/files/book.pdf >>> >>> FrankH. >>> >>>> >>>> cfa100 @ /net/coresvr/export/cores1/6570886plipstick1 $ mdb 5 >>>> mdb: warning: dump is from SunOS 5.10 Generic_125101-07; dcmds and >>>> macros may not match kernel implementation >>>> Loading modules: [ unix krtld genunix dtrace specfs >>>> cpu.AuthenticAMD.15 >>>> uppc pcplusmp ufs ipc ip sctp usba uhci s1394 fcp fctl emlxs qlc >>>> nca md >>>> lofs crypto zfs random cpc fcip logindmux ptm sppp ] >>>> > >>>> > ::status >>>> debugging crash dump vmcore.5 (64-bit) from plipstick1 >>>> operating system: 5.10 Generic_125101-07 (i86pc) >>>> panic message: BAD TRAP: type=d (#gp General protection) >>>> rp=fffffe8002012b80 addr=80a8000 >>>> dump content: kernel pages only >>>> > $c >>>> __1cG_SListJfind_elem6Mpvppn0AIListElem__3_+0x45() >>>> __1cSservice_admin_implN_unreferenced6Mpv_v_+0x3c() >>>> __1cPreplica_handlerNunref_by_ckpt6M_v_+0x172() >>>> __1cGhxdoorNunref_by_ckpt6M_v_+0x182() >>>> __1cOhxdoor_managerPrelease_by_ckpt6MrnJhxdoor_id__v_+0x116() >>>> __1cTckpt_handler_serverHprocess6MrnHservice__v_+0x2cb() >>>> __1cJckpt_elemHexecute6M_v_+0x4d() >>>> __1cTthreadpool_worker_tVdeferred_task_handler6M_v_+0x184() >>>> __1cKthreadpoolOthread_handler6FpnTthreadpool_worker_t__v_+0x25() >>>> cllwpwrapper+0x106() >>>> thread_start+8() >>>> > >>>> >>>> This is a serious limitation. I finally used ACT to see the parameters >>>> but it also was not showing proper parameters all the time. >>>> >>>> Is this a known issue ? >>>> Is there any other way to see the parameters ? >>>> >>>> -- >>>> Thanks, >>>> Tirthankar >>>> >>>> _______________________________________________ >>>> mdb-discuss mailing list >>>> mdb-discuss at opensolaris.org >>>> >>