• 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
SOLVED: Using Xcode debugger without Xcode project
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

SOLVED: Using Xcode debugger without Xcode project


  • Subject: SOLVED: Using Xcode debugger without Xcode project
  • From: Dieter Oberkofler <email@hidden>
  • Date: Wed, 5 Sep 2007 09:53:36 +0200

Jim,
It was the "Load Symbols Lazily" setting that caused the problems.
Thank you,
Dieter


On Aug 29, 2007, at 7:27 PM, Jim Ingham wrote:

For debugging PPC on PPC, if you are able to run your test app in the debugger, but just not hit breakpoints, you are probably getting bitten by the "lazy symbol loading" optimization. This is a way for Xcode to minimize the symbol set that the debugger has to read, but it depends on Xcode knowing what binaries a given project/ target produces, which in the case of Makefile targets it doesn't... Make sure that the "Load Symbols Lazily" setting in the Debugger tab of the Xcode preferences is unchecked.

Debugging PPC apps run under Rosetta on an Intel machine isn't supported in Xcode currently. It is possible in command-line gdb, but it isn't suggested unless your app only exhibits a bug when run under Rosetta, and not natively on PPC.

Jim

On Aug 29, 2007, at 9:42 AM, Dieter Oberkofler wrote:

Kyle,

Got the message but:

1) In my case I cannot build a universal binary because I'm using a 3rd party library that does only exist as PowerPC dynamic library.
2) I'm also unable to debug the PowerPC application on the PowerPC platform.


Cheers,
Dieter

On Aug 29, 2007, at 6:05 PM, Kyle Sluder wrote:

I'm suggesting that you build a universal binary and try debugging
that.  Attempting to debug a PowerPC app on Intel (when you're not
explicitly debugging its ability to run on Intel) is like going to a
veternarian for chest pains.

--Kyle Sluder

On 8/29/07, Dieter Oberkofler <email@hidden> wrote:
Kyle,

Sorry but I do not really understand:
1) I'm aware that PowerPC binaries do run under Rosetta on the Intel
platform but does this mean, that I cannot debug them on a an Intel?
2) I nevertheless am also unable to debug my makefile based
application on the PowerPC.


Cheers,
Dieter

On Aug 29, 2007, at 4:07 PM, Kyle Sluder wrote:

Are you forgetting that PowerPC binaries have to run under Rosetta on
Intel? I can't take an engine meant for a school bus and drop it in
my sedan...


--Kyle Sluder

On 8/29/07, Dieter Oberkofler <email@hidden> wrote:

I have been playing around with this for a while but am still stuck. I used all the advice that was given me but am still unable to debug an application build with an external makefile in XCode.

This is, where I currently am:
1) Because I was was unable to get the main application to work in
the XCode
debugger, I'm now using a very simple "Hello World" style
application and
would like to track my problem down in this simplified environment.
2) To make things even more complicate I'm now able to debug this
sample
project on one Mac and it does not work on another Mac.
3) When trying to debug the application I simply open one of the
source
files and set a breakpoint. When then running the application in the
debugger it breaks on one Mac and does not on the other one.
Is there any way to track down why the debugger does not break
when hipping
a (properly set) breakpoint?
4) One mac is a G5 based system and the other one is an Intel
based system.
The application itself has been build as a PowerPC application and
I'm able
to debug on the G5 but not on the Intel one. This would all point
to "some"
problem with the different architecture but unfortunately main main
applications cannot be debugged on any of the two systems.
Are there any significant restrictions when debugging a PowerPC
application
on an Intel mac and vice versa?
5) The only difference in the configuration (I can notice) is as
follows:
A breakpoint is set in the files main.cpp and sub.cpp (e.g. main
() - Line
10). The application generates a binary named hello.
On the PowerPC (where it is working) the list of breakpoints
(Debug>Breakpoints) are shown with a Location = "main.cpp - hello".
On the Intel Mac the same projects shows a list of breakpoints
where the
Location = "english" or main.cpp but without the "- hello" appendix
This all seems to indicate that the XCode debugger does not "know"
about the
right location of the source files but I'm unable to track down
the source
of the problem.


Any help is really appreciated,

Dieter



On Jul 31, 2007, at 12:29 AM, Chris Espinosa wrote:



On Jul 30, 2007, at 2:19 PM, Jeffrey Oleander wrote:

Hmmm,  my knee-jerk reaction to the question was in another
direction.

Isn't the debugger that Xcode uses gdb?  "Xcode debugger
without Xcode" sounds like gdb to me.
gdb is a command line interface.

Xcode Debugger is a GUI that sits on top of gdb.

What the OP wants is a GUI debugger on a makefile project, without
having to
build the project in Xcode. And Xcode can do that; the hack is
you have to
a) create a null project beforehand (you don't have to build the
sources in
Xcode), and b) you have to manually point the debugger at the
process and
your sources.


But once you have that, it does work, and believe me, it's much
nicer than
's s s s s' in the Terminal.

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

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:
40gmail.com

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:
40apple.com


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


  • Prev by Date: Re: .#_XCSCM_ files?
  • Next by Date: -mlong-branch
  • Previous by thread: Re: Distributed build problems - unknown compiler error and not building locally... On Sep 1, 2007, at 11:25 AM, Bill Bumgarner wrote: On Aug 31, 2007, at 4:12 PM, Dave Thorup wrote: On Aug 31, 2007, at 8:26 AM, Ken Worley wrote: On Aug 30, 2007, at 7:08 PM, Dave Thorup wrote: Now, for my second problem, when doing distributed builds only the remote machine is being sent files to compile, my local machine isn't compiling anything. This is verified by checking the DISTCC_HOSTS variable in the Xcode build log. If I turn off distributed builds on the remote machine then it will use the local machine to compile, but that seems to be the only way I can get compiles working on the local machine. The remote machine is a Core Duo iMac while the local Machine is a Quad Mac Pro, so naturally I'd like to be utilizing the local machine as well. From what I understand, this "problem" is actually by design. It's a real pain too if you happen to be working on the fastest mach ine available for building. I hope this will change in later versions. I haven't tried 2.5 yet. distcc requires the source files to effectively be precompiled prior to compilation. This puts a huge amount of potential I/O load and a bit of CPU load on the local system. As a result, the # of local jobs was turned down so that the machine could distribute jobs more efficiently. It sounds like it was turned down too much or a bug has come into play. Please file a bug capturing the symptoms and configuration. From what I gather in the list archives, this was an intentional change between 2.3 and 2.4. Someone complained to DTS and was told that engineering had determined that was the correct behavior. Hopefully, their notion of correct behavior has changed for 2.5...perhaps filing bugs will nudge them in the right direction. Ken -- Ken Worley Software Engineer, Tiberius, Inc.
  • Next by thread: -mlong-branch
  • Index(es):
    • Date
    • Thread