[comp.sys.amiga] SDB failing to load program

jack@cca.CCA.COM (Jack Orenstein) (06/21/88)

I've been using SDB without any problems for several months. Last night,
it would go through the motions of loading my program, but it would not
display the source code even though the source file was present in the
current directory. There were no error messages reported from SDB.  The
program seemed to be present since a command such as "t" caused it to
execute.  The executable and the .dbg file are large, about 145K each,
but I've used SDB successfully with a slightly larger version of the
same program.  The system is an A2000 with 3 meg, set up with a 1.5 meg
vd0: and the executable stuff in ram:.

Can anyone provide a lead on this?


Thanks

Jack Orenstein



This is not a disclaimer.

baer@percival.UUCP (Ken Baer) (06/24/88)

In article <29778@cca.CCA.COM> jack@cca.CCA.COM (Jack Orenstein) writes:
>
>I've been using SDB without any problems for several months. Last night,
>it would go through the motions of loading my program, but it would not
>display the source code even though the source file was present in the
>current directory. 
>Jack Orenstein

Sounds like you didn't compile it with -n.  This happens to me a lot when
I have a big MakeFile.  Did you remember to specify -n for that file in
your MakeFile.  Example:

test.o:
   cc -n test

If you compile the file without the -n flag, the symptoms are as you 
described.  I use 2 makefiles, one with the -n stuff and one without.
Hope this helps.

-- 
	-Ken Baer.  					 
   //   Hash Enterprises: When the Going gets Weird, the Weird go Professional
 \X/    USENET - ...tektronix!reed!percival!baer   OR   baer@percival.UUCP,
        BIX - kbaer,  "while (AINTGOTNOSATISFACTION) { do stuff }" - RJ Mical

jack@cca.CCA.COM (Jack Orenstein) (06/27/88)

In article <1275@percival.UUCP> baer@percival.UUCP (Ken Baer) writes:
>In article <29778@cca.CCA.COM> jack@cca.CCA.COM (Jack Orenstein) writes:
>>
>>[sdb doesn't display source code but program loads]
>
>Sounds like you didn't compile it with -n.  This happens to me a lot when
>I have a big MakeFile.  Did you remember to specify -n for that file in
>your MakeFile.  

Yes, that was it and boy do I feel stupid. I HAD the -n flag, but I changed
my makefile to compile from a vd0: directory into ram:, screwed it up,
so cc used the default .c.o dependency, not mine (which had the -n flag).

Never mind.

Jack Orenstein



This is not a disclaimer.

phils@tekigm2.TEK.COM (Philip E Staub) (06/28/88)

In article <1275@percival.UUCP> baer@percival.UUCP (Ken Baer) writes:
<In article <29778@cca.CCA.COM> jack@cca.CCA.COM (Jack Orenstein) writes:
<>
<>I've been using SDB without any problems for several months. Last night,
<>it would go through the motions of loading my program, but it would not
<>display the source code even though the source file was present in the
<>current directory. 
<>Jack Orenstein
<
<Sounds like you didn't compile it with -n.  This happens to me a lot when
<I have a big MakeFile.  Did you remember to specify -n for that file in
<your MakeFile.  Example:
<
<test.o:
<   cc -n test
<
<If you compile the file without the -n flag, the symptoms are as you 
<described.  I use 2 makefiles, one with the -n stuff and one without.
<Hope this helps.
<
<-- 
<	-Ken Baer.  					 

These days, I *always* compile with the -n switch and link with the -g
switch. I do this because I discovered that compiling and linking with and
without the debugging switches produced exactly the same size executable file.
Apparently, the only difference is in the size of the .o files and the
presence of the .dbg file, which the debugger uses to find it's references.
Also, I find that using the debugging switches has notified me of structures
which I've declared pointers to but never defined, which the non-debugging
environment doesn't do.

Bottom line - if I've got enough disk space plus a little extra time (never 
timed it, but I'd be surprised if it didn't take a bit longer to compile and
link), I'll include the debugging switches.

-
Phil
-- 
------------------------------------------------------------------------------
Phil Staub        
Tektronix, Inc., Vancouver, Washington 98668
phils@tekigm2.MEN.TEK.COM