• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: DWARF problems?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: DWARF problems?


  • Subject: Re: DWARF problems?
  • From: Jim Ingham <email@hidden>
  • Date: Fri, 26 May 2006 10:20:56 -0700

Can you file a bug about this. It would be most helpful if you could do the following:

1) Make a file in your home directory called .gdbinit, and put in it:

set mi-timings-enabled on

2) Enable the Xcode-gdb log by:

  a) Quit Xcode.
  b) In Terminal, say:

$ defaults write com.apple.Xcode PBXGDBDebuggerLogToFile YES
$ defaults write com.apple.Xcode PBXGDBDebuggerLogFileName /tmp/ IncludeInBug.log


3) Restart Xcode, and do a few steps where the steps are slow. The more steps you do the more data we will have to analyze...
4) Attach /tmp/IncludeInBug.log to the Radar.


That will give us the timings both on the gdb side and on the Xcode side for all the operations we perform, and we can see if there's anything that stands out.

The "not enough frames..." is a harmless error. We have a fast way of computing the stack, which is mostly but not always accurate. We use that when you step just to see if the stack has changed. If it has, we use our slow stack computing to get the new stack. Otherwise, we don't need to do this operation - which can speed up stepping a good bit when the stack is deep. Sometimes the fast way gets too many stack frames, and when we run the slow method we get this error. But the stack was fetched correctly.

Thanks,

Jim



On May 26, 2006, at 8:15 AM, Steve Mills wrote:

On May 26, 2006, at 09:24, Steve Mills wrote:

I changed our main project to use DWARF. On the machine I changed it on (dual 2.somethingGHz G5), it really made a difference in debugging speed. I checked in the project, synced to it on another machine (dual 2GHz G5), cleaned the project to make sure all previous object/debug data was gone, and built. Debugging seems to be as slow as it ever was with Stabs. Any ideas? I have not yet changed all of the subprojects over to DWARF, but plan to. However, the code I'm stepping through is nowhere near any of the subproject code.

Today I'm getting a debugger error at the bottom of the window when I stop at a breakpoint and step through code: "mi_cmd_stack_list_frames: Not enough frames in stack." What does this mean?

Hmm, another full clean and build seems to have cleared up the stack frame problem. But debugging is still slow as molasses - nearly 10 seconds a step, just like with 2.2.1 and Stabs.


Steve Mills
Drummer, Mac geek
http://sjmills5.home.mchsi.com/


_______________________________________________ Do not post admin requests to the list. They will be ignored. Xcode-users mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: This email sent to email@hidden

_______________________________________________ Do not post admin requests to the list. They will be ignored. Xcode-users mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: This email sent to email@hidden
  • Follow-Ups:
    • Re: DWARF problems?
      • From: Steve Mills <email@hidden>
References: 
 >DWARF problems? (From: Steve Mills <email@hidden>)
 >Re: DWARF problems? (From: Steve Mills <email@hidden>)

  • Prev by Date: mpi programme broken with new gcc 4.0.1?
  • Next by Date: Re: XCConfig file stoped working
  • Previous by thread: Re: DWARF problems?
  • Next by thread: Re: DWARF problems?
  • Index(es):
    • Date
    • Thread