GDB Issues

[Lawrence_Selvy]

Hello,I am working on a very large body of code (~80k lines) and I would like to be able to debug using GDB. I have been working for a few days to be able to compile this fortran source in a way that would let me use GDB, but have been unsuccessful so far.I have been using the -g -debug -debug-parameters all options in my code.When I open the executable with GDB it saysGNU gdb (GDB) Red Hat Enterprise Linux (7.0.1-37.el5_7.1)Copyright (C) 2009 Free Software Foundation, Inc.License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>This is free software: you are free to change and redistribute it.There is NO WARRANTY, to the extent permitted by law. Type "show copying"and "show warranty" for details.This GDB was configured as "x86_64-redhat-linux-gnu".For bug reporting instructions, please see:<http://www.gnu.org/software/gdb/bugs/>...Reading symbols from EXECUTABLE...(no debugging symbols found)...done.(I left the version info there on purpose). I can set breakpoints and the work. It will list source code, but when I attempt to print a variable it fails. I am not sure why this is, but this is important functionality.Is there a flag or something I am not setting? I have even tried using the -dwarf-2/3 flags.Thanks in advance,Larry

[Ron_Green]

Larry,

I am going to move this thread over to our new Debugger Solutions User Forum.

ron

[Rob_Mueller-Albrecht]

Hi Larry,

this might be an issue with GDB itself that is better addressed at http://www.gnu.org/software/gdb/mailing-lists/.

That said let me try to see whetehr we can identify the problem more clearly.

Since you can list source code inside GDB and also set breakpoints, the most likely root cause would be that optimizations force some variables to be propageted in registers and the symbol info for those variable sbeing lost.

However - you do get the message (no debugging symbols found). This is the message you would get if -g does not get passed on correctly to the linker and the symbol info gets stripepd out again somewhere in the build process.

Can you provide me with

One typical complete compiler build/options line?
One complete linker command line?

My suspicion at first glance would be that you loose your symbol info other than basic function level info during the link step.

Thanks, Rob

[Lawrence_Selvy]

Hello Rob,

Here is the typical compiler build options line:

ifort -g -debug -fpe0 -fp-stack-check -traceback -debug extended -debug-parameters all -O0 -vec-report0

I know some of those options don't make sense (vec-report0 for a -g -O0) but that is what I inheritted.

Here's a typical linker command:

ifort -g -debug -fpe0 -fp-stack-check -traceback -debug extended -debug-parameters all -O0 -vec-report0 -u -I../incl_g -c ParseIt.f90

From what I know, the -g gets passed alright and there isn't a strip flag sent. Could it be that we aren't linking (-c)?

Larry

[Rob_Mueller-Albrecht]

Hi Larry,

the options as such look ok. It looks as though you are using the compiler driver (ifort) to pass the objects to the linker ld to do the linking.

Perhaps you can try to add the -Xlinker option (after all the compile roptions) and specify -debug there for the linker explicitly as well.

If this doesn't help we would probably have to have a look at the generated binary with the readelf utiltiy to confirm that there is indeed no symbol info in the object.

Thanks, Rob

[Lawrence_Selvy]

Hello,

I have gone ahead and done what you asked, here is the new compilation line:

ifort -g -debug -fpe0 -fp-stack-check -traceback -debug extended -debug-parameters all -O0 -vec-report0 -u -I../incl_g -Xlinker -debug -c ParseIt.f90

I have also opened the binary up in readelf and there only seems to be function, object, and no type sumbol types in there. Not sure what could be causing that. Any ideas?

-Larry

[Rob_Mueller-Albrecht]

Hmm,

ok - so we at least know now that we are looking for the problem in the right place. Somehow the symbol info does not make it into the final executable.

Could you follow up with a private response that contains acomplete build log and your makefile /.configure build setup.

I will have to look at it in more detail to find out where the ball gets dropped I am afraid.

Thanks, Rob

[Lawrence_Selvy]

Hello again,

I have written a small test program to help out that uses a module.

the complete build sequence is as follows:

ifort -g morehello.f90 -c -o morehello.o

ifort -g hello.f90 morehello.f90 -o hello.o

When I use gdb on hello.o I get the same message as before:

Reading symbols from hello.o...(no debugging symbols found)...done.

When I stop in the module and do a bt full I get:

#0 0x0000000000402c16 in morehello_mp_foobar_ ()

No symbol table info available.

#1 0x0000000000402b99 in hello () at hello.f90:18

hi =

stuff = 0

resultant = 50000

var2 = 500

var1 = 100

#2 0x0000000000402a8c in main ()

No symbol table info available.

So I can see the variables in the main program, but not in the module. Looking at the symbol table I am unable to locate the variables used in the function in the module (although varaibles defined on the module level are available using the modulename_variablename_ mangling scheme).

The programs are very simple, less than 13 lines each. The do some math (arithmatic) and print statements.

-Larry

[Lawrence_Selvy]

Sorry I wanted to include the relevant lines from readelf:

56: 0000000000000000 0 FILE LOCAL DEFAULT ABS morehello.f90

57: 000000000069f608 8 OBJECT LOCAL DEFAULT 23 morehello_mp_foobar_$BARF

58: 000000000069f610 4 OBJECT LOCAL DEFAULT 23 morehello_mp_foobar_$MULT

These are the lines that seem to represent the variables in the readelf symbols output

[Rob_Mueller-Albrecht]

Dear Larry,

are you able to reproduce the same behavior if you are using IDB instead of GDB? IDB is part of the Composer XE installation you are using to run the Intel Fortran Compiler - and it is tested more extensively against ifort.

It may be helpful to see how the Intel Debugger reacts.

Are you also checking with the open source GDB community in parallel?

From your description it sounds more and more as though we are dealing with a scope issue instead of a symbol info table issue. Although I don't know why GDB would state that there is no symbol info table information. That is contradicting what we see,

Ifyou would like you could forward your small hello world test case to me as a private attachement and I'll run some tests on my end as well.

Thanks, Rob

[Lawrence_Selvy]

We have tested this in IDB and it works without a problem. Same symbol information and the like, but it works. I was hoping to use GDB for a number of reasons (although IDB is an excellent debugger). So it seems like the defect is with GDB.

I have been looking through posts and the list and I have seen that oder versions of GDB seem to create a problem, so I have asked our system administrator to upgrade to the newest (I have v7.0 and newest is 7.2).

I agree now that this is a scoping issue, but I am unsure how to make gdb scoping work out. I will continue to work around in the open source community, but any help would be appreciated.