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