- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi folks,
I wonder if anybody here can help me...
I got myself the latest Intel fortran Composer XE for mac OSX (ifort 12.0) as it was advertised that it could be used with Xcode on OSX, a nice development tool. Now i see that i can edit and compile from within Xcode, but in real practice I can't debug since global variables (in modules and commons) are not recognized. I mean to say, global variables are supposed to be used throughout the whole code (that's why they are made global afterwards) and I see no way to check/modify their values.
So diving on the internet I saw this problem was already reported in the past, and though that wth the advertisement of being the new release integrated in Xcode, all that would have been solved. But i don't see how...
So my questions are a few :)
1) Has anybody solved this problem, or is everybody else having the same issues?
2) Does anybody know if there is any way to tell Xcode to use idb instead of gdb for debugging?
3) Is there any plan to fix that?
What I can't really understand is that Intel is advertising the integration of ifort in the Xcode development enviroment, to find that it can't really be used for debugging (so what's the point?).
I hope I am wrong in my points, but any opinion about that will be appreciated...
I wonder if anybody here can help me...
I got myself the latest Intel fortran Composer XE for mac OSX (ifort 12.0) as it was advertised that it could be used with Xcode on OSX, a nice development tool. Now i see that i can edit and compile from within Xcode, but in real practice I can't debug since global variables (in modules and commons) are not recognized. I mean to say, global variables are supposed to be used throughout the whole code (that's why they are made global afterwards) and I see no way to check/modify their values.
So diving on the internet I saw this problem was already reported in the past, and though that wth the advertisement of being the new release integrated in Xcode, all that would have been solved. But i don't see how...
So my questions are a few :)
1) Has anybody solved this problem, or is everybody else having the same issues?
2) Does anybody know if there is any way to tell Xcode to use idb instead of gdb for debugging?
3) Is there any plan to fix that?
What I can't really understand is that Intel is advertising the integration of ifort in the Xcode development enviroment, to find that it can't really be used for debugging (so what's the point?).
I hope I am wrong in my points, but any opinion about that will be appreciated...
Link Copied
11 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I do not use OSX, so view these as non-denominational comments.
(i) Debuggers are usually written for the dominant customers, i.e., C/C++ and Java programmers. Fortran support, especially for Fortran 95/2003 features, can be missing or inadequate, or added after delays.
(ii) Marketing, software development and customer service divisions have quite different world-views and their statements should always be seen through the appropriate prism.
Please see if this article will help with your stumbling block:
Viewing Fortran Data Types in the Microsoft Debugger
In essense, you prefix the variable with the module name, common block variables with the block name, etc.
(i) Debuggers are usually written for the dominant customers, i.e., C/C++ and Java programmers. Fortran support, especially for Fortran 95/2003 features, can be missing or inadequate, or added after delays.
(ii) Marketing, software development and customer service divisions have quite different world-views and their statements should always be seen through the appropriate prism.
Please see if this article will help with your stumbling block:
Viewing Fortran Data Types in the Microsoft Debugger
In essense, you prefix the variable with the module name, common block variables with the block name, etc.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The Intel Fortran integration into Xcode is a "limited feature", which means it does some things and not others. Debugging is one of those weak spots. Intel is blocked in our ability to fully integrate into Xcode by several long-outstanding bugs reported to Apple. There are no plans to improve our Xcode integration, sadly.
There have been several posts about debugging under Mac OS X in this forum. IDB supplied with your compiler is an excellent Fortran-aware debugger. And there is a way to wrap a GUI, DDD, around IDB. But no, no known way to get Xcode to use IDB, unfortunately.
Here is another post for reference:
http://software.intel.com/en-us/forums/showthread.php?t=63601&o=a&s=lr
and the reference for wrapping IDB with the DDD GUI:
http://software.intel.com/en-us/forums/showthread.php?t=60060
There have been several posts about debugging under Mac OS X in this forum. IDB supplied with your compiler is an excellent Fortran-aware debugger. And there is a way to wrap a GUI, DDD, around IDB. But no, no known way to get Xcode to use IDB, unfortunately.
Here is another post for reference:
http://software.intel.com/en-us/forums/showthread.php?t=63601&o=a&s=lr
and the reference for wrapping IDB with the DDD GUI:
http://software.intel.com/en-us/forums/showthread.php?t=60060
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Oh well, thanks for all these quick replays...
Yes I know the intel debugger idb works like a charm, that's why i was wondering if there was a way to integrate that into Xcode instead of using gdb.
And well... DDD gui looks really ugly (to MY eyes), while Xcode looks much nicer. But then why not porting to OSX the same idb gui front end found in other OS as for instance Linux? I use that one at work and I'm fairly happy with it.
So somehow my point is that debugging is important for programmers. Command line debugging is possible (and good when you have no other thing) but very old fashioned and much less comfortable as with visual/gui fornt ends.
intel already has a nice tool for doing that, but decides not to include it in the OSX version because there is already a nice development tool 8Xcode) there, but then that can not work with ifort. All in all, the result is that the user does not have it... when Intel already has a wonderful tool for that.
So what's the point?
Yes I know the intel debugger idb works like a charm, that's why i was wondering if there was a way to integrate that into Xcode instead of using gdb.
And well... DDD gui looks really ugly (to MY eyes), while Xcode looks much nicer. But then why not porting to OSX the same idb gui front end found in other OS as for instance Linux? I use that one at work and I'm fairly happy with it.
So somehow my point is that debugging is important for programmers. Command line debugging is possible (and good when you have no other thing) but very old fashioned and much less comfortable as with visual/gui fornt ends.
intel already has a nice tool for doing that, but decides not to include it in the OSX version because there is already a nice development tool 8Xcode) there, but then that can not work with ifort. All in all, the result is that the user does not have it... when Intel already has a wonderful tool for that.
So what's the point?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello!
On a sliglty related note: is it normal that even using IDB I'm not able to see/check the variables defined inside modules? The odd thing(at least for me) is that if a put i write statement of the variable in the code I now can see it...
Cheers!
Luca
On a sliglty related note: is it normal that even using IDB I'm not able to see/check the variables defined inside modules? The odd thing(at least for me) is that if a put i write statement of the variable in the code I now can see it...
Cheers!
Luca
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Luca,
Can you also put in
IF(ExpressionAlwaysFalseButCompilerCannotSeeAsFalse) THEN
WRITE(*,*) Your, Global, variables, of, interest, here
ENDIF
Then with IDB have access to these variables?
IOW and IF block that will neverbe executed .AND. does not appear as dead code to the compiler (else it may/will remove the dead code).
If so, then I would venture to guess that the compiler isaddingdebug symbol alias of the module name prefixed global sysmbol name.
Jim Dempsey
Can you also put in
IF(ExpressionAlwaysFalseButCompilerCannotSeeAsFalse) THEN
WRITE(*,*) Your, Global, variables, of, interest, here
ENDIF
Then with IDB have access to these variables?
IOW and IF block that will neverbe executed .AND. does not appear as dead code to the compiler (else it may/will remove the dead code).
If so, then I would venture to guess that the compiler isaddingdebug symbol alias of the module name prefixed global sysmbol name.
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi!
So just to be sure I'm not doing something terribly wrong here is a real basic sample code that contains the case that You pointed(not real sure about the CompilerCannotSeeAsFalse stuff though):
I should have said in my first post that this is happening while using Xcode 4 that I know is not yet officially supported(but I wanted to try anyway) so maybe I stumbled on an incompatibiliy with the new introduced linker
Cheers!
Luca
So just to be sure I'm not doing something terribly wrong here is a real basic sample code that contains the case that You pointed(not real sure about the CompilerCannotSeeAsFalse stuff though):
[fortran]module Data integer :: a = 1 end module Data program Test use Data integer :: b = 2 if(b.GT.5) then write(*,*) a end if end program Test[/fortran]So the program obviously never enters the if, but with the debugger the variable a is seen and has the correct value but as soon as i remove the write statement when i try to see it with the debugger i get the following error message:"No symbol "a" in current context. Cannot evaluate 'a'."
I should have said in my first post that this is happening while using Xcode 4 that I know is not yet officially supported(but I wanted to try anyway) so maybe I stumbled on an incompatibiliy with the new introduced linker
Cheers!
Luca
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Because you have a test on the variable 'b' at the very start of execution, and 'b' is initialized in the type declaration statement, this program does not pass the 'compiler-cannot-see' requirement. You need to put some statements that use 'b' before the IF statement. For example, a call to a subroutine in another file, which the compiler will see as something that is likely to change b, so that code to do the comparison is necessary.
In other words, on line-12 the answer to the question 'a > 5 ?' should be 'unknown at compile time.
In other words, on line-12 the answer to the question 'a > 5 ?' should be 'unknown at compile time.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Only module variables that are referenced in the routine are given debug symbols, so what you are seeing is completely expected.
idb understandsFortran well enough that one can specify MODULE::variable and it can find the debug symbol for "variable" in module"MODULE".
However, Xcode does not understand Fortran, and so, you can only seemodule variables that are explicitly referenced.
-- Lorri
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi!
Ok I see, I'm quite new to Fortran so I didn't know if it was expected behavior or some kind of bug.
Cheers!
Luca
Ok I see, I'm quite new to Fortran so I didn't know if it was expected behavior or some kind of bug.
Cheers!
Luca
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Luca,
something related that I'm inetersted in comes from your last paragraph here... you said you're playing with Xcode 4 (not 3.2.6 as I had), so i wonder if you can tell me how things regarding fortran have changed there.
Shall I understand from your words that under Xcode4 you really can see (at least some) variables defined in modules? And variables in COMMON blocks?
And dynamically allocated arrays in Modules and COMMON blocks?
BWT reading on the internet I've seen people complaining that Xcode4 does not provide synatx highlinghting for fortran anymore, but your piece of code appears in full technicolor... did you have to do anything/configure anything special to achieve this?
I ask all that because i may end up paying the $4 for Xcode4 if some of these problems happen to be solveable...
BTW regarding you piece of code and your complain about variable 'a' not being seen when you remove the 'write(*,*) a' statement, I cantell you that I have also tried that (your code) on my Linux box and find exactly the same behaviour you report. So that is not related to the OS but to the very own behaviour of idb as said by others...
One possible way to solve the problem, as suggested by Jim, is to use a condition that will never be executed but that the compiler can not know at compilation time. The simplest thing is to include a veriable in you input file (the file you use to feed in data to the program). for instance changing your code to somthing like thus
module Data
integer :: a = 1
end module Data
program Test
use Data
integer :: b = 2
integer :: c
print'(a)','Please provide the value of c : '
read*,c
if(c.eq.-1) write(*,*) a
continue
end program Test
does work well with idb (it prints a and b ok) and you only have to give variable 'c' a value diffferent from -1. Now you can do the same trick on an input file.
BTW if I compile with gfortran your program with the 'write(*,*) a' statement commented, debugging with gdb does yield the right balue of a and b, so at this point that combo seems to perform better than the ifort/idb one. Hoever, if I change your program to include a dynamically allocated array in the module and remove the 'write(*,*) a' statement, as:
module Data
integer :: a = 1
real*8, pointer, dimension(:) :: mat
end module Data
program Test
use Data
integer :: b = 2
integer :: c
allocate (mat(3))
do i=1, 3
mat(i)=1.d0*i
enddo
continue
end program Test
put a breakpoint at the 'continue' statement, it turns out that:
* ifort/idb: idb says b=2, says mat(1)=1, mat(2)=2 and mat(3)=3, but produce the'Cannot evaluate 'a'' message you report
* gfortran/gdb: gdb says a=1 and b=2, but 'no such vector element' when requested for mat(1)...
cheers,
Ferran.
something related that I'm inetersted in comes from your last paragraph here... you said you're playing with Xcode 4 (not 3.2.6 as I had), so i wonder if you can tell me how things regarding fortran have changed there.
Shall I understand from your words that under Xcode4 you really can see (at least some) variables defined in modules? And variables in COMMON blocks?
And dynamically allocated arrays in Modules and COMMON blocks?
BWT reading on the internet I've seen people complaining that Xcode4 does not provide synatx highlinghting for fortran anymore, but your piece of code appears in full technicolor... did you have to do anything/configure anything special to achieve this?
I ask all that because i may end up paying the $4 for Xcode4 if some of these problems happen to be solveable...
BTW regarding you piece of code and your complain about variable 'a' not being seen when you remove the 'write(*,*) a' statement, I cantell you that I have also tried that (your code) on my Linux box and find exactly the same behaviour you report. So that is not related to the OS but to the very own behaviour of idb as said by others...
One possible way to solve the problem, as suggested by Jim, is to use a condition that will never be executed but that the compiler can not know at compilation time. The simplest thing is to include a veriable in you input file (the file you use to feed in data to the program). for instance changing your code to somthing like thus
module Data
integer :: a = 1
end module Data
program Test
use Data
integer :: b = 2
integer :: c
print'(a)','Please provide the value of c : '
read*,c
if(c.eq.-1) write(*,*) a
continue
end program Test
does work well with idb (it prints a and b ok) and you only have to give variable 'c' a value diffferent from -1. Now you can do the same trick on an input file.
BTW if I compile with gfortran your program with the 'write(*,*) a' statement commented, debugging with gdb does yield the right balue of a and b, so at this point that combo seems to perform better than the ifort/idb one. Hoever, if I change your program to include a dynamically allocated array in the module and remove the 'write(*,*) a' statement, as:
module Data
integer :: a = 1
real*8, pointer, dimension(:) :: mat
end module Data
program Test
use Data
integer :: b = 2
integer :: c
allocate (mat(3))
do i=1, 3
mat(i)=1.d0*i
enddo
continue
end program Test
put a breakpoint at the 'continue' statement, it turns out that:
* ifort/idb: idb says b=2, says mat(1)=1, mat(2)=2 and mat(3)=3, but produce the'Cannot evaluate 'a'' message you report
* gfortran/gdb: gdb says a=1 and b=2, but 'no such vector element' when requested for mat(1)...
cheers,
Ferran.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi!
So after playing a little bit with Xcode 4 here are the things tha don't work:
1) Debugging: as already said Xcode uses gdb so it will not see variables defined inside modules(not really sure about common blocks because I try to avoid them as much as I can). I understand that this is a problem that will not be solved in the short term as it depends heavily on Apple.
2) When you want to create a new file the Fortran option is no longer there. I made it reappear by changing the extension of the folders in /Developer/Library/Xcode/Templates/File Templates/Fortran from .pbfiletemplate to xctemplate.
3) The synatx highlinghting for fortran also has dissapeared: I'm investigating a little bit but I expect that this issue will be addressed in a future update of the compiler.
Other than the issue everything else seems to work:I'm working on a project that compiles/builds fine with all the ifort specific options appearing in the build settings.
Cheers!
Luca
So after playing a little bit with Xcode 4 here are the things tha don't work:
1) Debugging: as already said Xcode uses gdb so it will not see variables defined inside modules(not really sure about common blocks because I try to avoid them as much as I can). I understand that this is a problem that will not be solved in the short term as it depends heavily on Apple.
2) When you want to create a new file the Fortran option is no longer there. I made it reappear by changing the extension of the folders in /Developer/Library/Xcode/Templates/File Templates/Fortran from .pbfiletemplate to xctemplate.
3) The synatx highlinghting for fortran also has dissapeared: I'm investigating a little bit but I expect that this issue will be addressed in a future update of the compiler.
Other than the issue everything else seems to work:I'm working on a project that compiles/builds fine with all the ifort specific options appearing in the build settings.
Cheers!
Luca
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page