Yes. You're right. The GNUmakefile I edited is made jup of a number of sections, one for each system the program has been ported to. I mae the changes in the wrong section. When I realized that I made the changes in the Linux section and recreated the executable. I launched DDD and opened the new executable. This time DDD does show the source code. If I click on File-->Open-Source a drop down menu pops up showing a list of Fortran and C source files. But it is still complaining with the same messsage: /home/mauede/mars15/sysdeps/i386/elf/start.S: No such file or directory. Moreover ddd is using the 64-bit libraries as declared in the first lines it prints out in the execution window:
GNU DDD 3.3.10 (x86_64-suse-linux), by Dorothea LUsing host libthread_db library "/lib64/tls/libthread_db.so.1". (gdb) list init.c:1 Line number 1 is out of range for "init.c". (gdb) in init.c (gdb) list m1505.f:1 Line 1 of "m1505.f" starts at address 0x804ecb0 <mars1505_> and ends at 0x804ecb6 <mars1505_+6>. (gdb) list marsmain.f:1 Line 1 of "marsmain.f" starts at address 0x804eb48 <MAIN__> and ends at 0x804eb4e <MAIN__+6>. (gdb) list start.S:1 Line 1 of "start.S" is at address 0x804ea90 <_start> but contains no code. (gdb) in ../sysdeps/i386/elf/start.S (gdb) list crtn.S:1 Line 1 of "/usr/src/packages/BUILD/glibc-2.3/cc/csu/crtn.S" is at address 0x804d531 <_init+21> but contains no code. (gdb) in /usr/src/packages/BUILD/glibc-2.3/cc/csu/crtn.S (gdb) list crtn.S:1 Line 1 of "/usr/src/packages/BUILD/glibc-2.3/cc/csu/crtn.S" is at address 0x804d531 <_init+21> but contains no code. (gdb) list hbook.h:1 Line 1 of "hbook.h" is at address 0x8050438 <__cf__HEXIST> but contains no code. (gdb) list m15gui.c:1 Line 1 of "m15gui.c" is at address 0x804f698 <matrix3d_det> but contains no code. (i-search)`': break m15gui.c:1586 Breakpoint 1 at 0x8052e06: file m15gui.c, line 1586. (gdb) set args (gdb) run [Thread debugging using libthread_db enabled] [New Thread 1434560192 (LWP 7596)] START MARS initialization
The list of soutce files (Open Source) shows, among some native routines making up the program, also the following: crti.S crtn.S start.S
If I click on start.S and then on the Open button I see the following: 1 ../sysdeps/i386/elf/start.S: No such file or directory.
If I click on crti.S and then on the Open button I see the following: 1 /usr/src/packages/BUILD/glibc-2.3/cc/csu/crti.S: No such file or directory.
If I click on crtn.S and then on the Open button I see the following: 1 /usr/src/packages/BUILD/glibc-2.3/cc/csu/crtn.S: No such file or directory.
Appearantly it allows me to proceed. But I wonder what are those fictitious source files ".S" and how those wierd messages are going to affect DDD reliability and debugging capabilities.
Thank you very much for your help.
On Mon, 15 May 2006, Ken Jennings wrote:
On Monday 15 May 2006 18:25, Maura Edeweiss Monville wrote: [...]
Then I replaced the original compiler and linker options: CFLAGS := -O3 -xarch=v8 LDFLAGS := -fast -xarch=v8 -xlang=f77 -L/usr/openwin/lib
with the following: CFLAGS := -g -xarch=v8 LDFLAGS := -fast -g -C -xs -xildoff -xarch=v8 -xlang=f77 -L/usr/openwin/lib
Ummmm? What is xarch=v8 expected to do on an x86 architecture? I've only seen it in Solaris (and there it basically means "use an older, mostly 32-bit CPU model").
-- To unsubscribe, email: firstname.lastname@example.org For additional commands, email: email@example.com Archives can be found at: http://lists.suse.com/archive/suse-programming-e