For now, I fixed this in r191378 using self.res.GetOutput() after self.runCmd(). Thanks again for root-causing this one,
- Ashok -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Thirumurthi, Ashok Sent: Wednesday, September 25, 2013 11:10 AM To: Richard Mitton; [email protected] Subject: Re: [lldb-dev] Missing function arguments in the backtrace Bingo, thanks! TestInferiorAssert.py passes for me with the attached patch. Even better, it would be nice to cache the initial result of runCmd("settings show frame-format") so that this doesn't drift with changes to default settings... - Ashok -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Richard Mitton Sent: Tuesday, September 24, 2013 10:24 PM To: [email protected] Subject: Re: [lldb-dev] Missing function arguments in the backtrace I think you might be looking at the same bug that I am. The problem is that TestSettings.py changes the frame format string, and doesn't restore it to the correct value. But I think the real problem is that dotest.py executes multiple tests using the same context (I just posted a mail about this). Richard Mitton [email protected] On 09/24/2013 07:19 PM, Jason Molenda wrote: > Ashok, for what it's worth I can't see what would cause this difference > between the two runs based on the log files. > > Is it possible that lldb is stopped at different places when the thread > backtrace all is invoked? The lldb unwind log isn't printing the pc values > of thread 1 frame 0. thread 1 is clearly the same in both - we have the > exact same pc value and we're using the same unwind instructions from the > eh_frame. > > This is a little odd - > > th1/fr2 looking for register saved location for reg 2 > th1/fr1 did not supply reg location for 2 (rcx) because it is volatile > th1/fr2 looking for register saved location for reg 16 > th1/fr1 supplying caller's saved reg 16's location, cached > th1/fr2 looking for register saved location for reg 8 > th1/fr1 did not supply reg location for 8 (r8) because it is > volatile > > Why would lldb be trying to examine something in rcx or r8 in frame 2 here? > There must be a variable whose location list says it is live at the call site > in that register - poor DWARF from the compiler. > > The fact that we don't see the same thing in the bt-fail.log case makes me > wonder if the debug info isn't different -- or absent? > > > On Sep 24, 2013, at 1:26 PM, Thirumurthi, Ashok <[email protected]> > wrote: > >> I have an Ubuntu 12.10 machine where inferior_asserting() succeeds when >> functionalities/inferior-asserting is run in isolation with either of clang >> or gcc, but fails when dotest.py is used to run the full suite. When it >> fails, the backtrace is missing all function arguments. A diff of the >> attached logs illustrates that RegisterContextLLDB comes up with a more >> complete register set in the passing case. >> >> Note: th1/fr1 frame uses eh_frame CFI for full UnwindPlan >> >> Any guesses from the logs where I'd be looking to root cause this funkiness?? >> >> - Ashok >> >> th1/fr2 looking for register saved location for reg 16 >> th1/fr1 supplying caller's saved reg 16's location, cached >> th1/fr2 looking for register saved location for reg 1 >> th1/fr1 could not supply caller's reg 1 location >> th1/fr0 supplying caller's register 1 from the live RegisterContext >> at frame 0 >> th1/fr1 looking for register saved location for reg 1 >> th1/fr0 supplying caller's saved reg 1's location, cached >> th1/fr0 looking for register saved location for reg 1 >> th1/fr0 passing along to the live register context for reg 1 >> th1/fr2 looking for register saved location for reg 16 >> th1/fr1 supplying caller's saved reg 16's location, cached >> th1/fr2 looking for register saved location for reg 12 >> th1/fr1 could not supply caller's reg 12 location >> th1/fr0 supplying caller's register 12 from the live RegisterContext >> at frame 0 >> th1/fr1 looking for register saved location for reg 12 >> th1/fr0 supplying caller's saved reg 12's location, cached >> th1/fr0 looking for register saved location for reg 12 >> th1/fr0 passing along to the live register context for reg 12 >> th1/fr2 looking for register saved location for reg 16 >> th1/fr1 supplying caller's saved reg 16's location, cached >> th1/fr2 looking for register saved location for reg 6 >> th1/fr1 could not supply caller's reg 6 location >> th1/fr0 supplying caller's saved reg 6's location, cached >> th1/fr1 looking for register saved location for reg 6 >> th1/fr0 supplying caller's saved reg 6's location, cached >> th1/fr0 looking for register saved location for reg 6 >> th1/fr0 passing along to the live register context for reg 6 >> th1/fr2 looking for register saved location for reg 16 >> th1/fr1 supplying caller's saved reg 16's location, cached >> th1/fr2 looking for register saved location for reg 2 >> th1/fr1 did not supply reg location for 2 (rcx) because it is volatile >> th1/fr2 looking for register saved location for reg 16 >> th1/fr1 supplying caller's saved reg 16's location, cached >> th1/fr2 looking for register saved location for reg 8 >> th1/fr1 did not supply reg location for 8 (r8) because it is volatile >> >> >> <bt-fail.log><bt-ok.log>_____________________________________________ >> __ >> lldb-dev mailing list >> [email protected] >> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev > _______________________________________________ > lldb-dev mailing list > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev _______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev _______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
