Sender:	richdawe AT bigfoot DOT com
Message-ID:	<379249F0.D17518C@tudor21.net>
Date:	Sun, 18 Jul 1999 21:41:04 +0000
From:	Richard Dawe <richdawe AT bigfoot DOT com>
X-Mailer:	Mozilla 4.51 [en] (X11; I; Linux 2.2.10 i586)
X-Accept-Language:	de,fr
MIME-Version:	1.0
To:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
CC:	DJGPP newsgroup <djgpp AT delorie DOT com>
Subject:	Re: Bizarre debugging format problem
References:	<Pine DOT SUN DOT 3 DOT 91 DOT 990718113123 DOT 19517V-100000 AT is>
Reply-To:	djgpp AT delorie DOT com

Hello.

Eli Zaretskii wrote:
> 
> On Sat, 17 Jul 1999, Richard Dawe wrote:
> 
> > I compiled & linked with
> > gcc's -g flag, but gdb could not find the line number information for
> > any of the functions. I tried changing -g to -g3, but this made no
> > difference. Trying -ggdb allowed me to do 'l main' and similar
> > successfully. Why is this?
> 
> (Sorry for going over trivia, but just in case...)

No problem, it reminds me what I forgot to mention ;)

> Was the problem with the functions in your main program, or in the
> libraries you linked in?  If the latter, you need to build the
> libraries with -g as well.

The problem was with the main program.

I built libsocket with debugging info using '-g'.

> Also, GDB needs to be told where to find the sources, for some
> source-oriented operations.

The program sources were in the same directory as the executable. I ran
gdb in this directory. I assumed that I don't have to tell gdb where *all*
the sources are, just the ones I'm interested in. I've never had to do
more than this before.

BTW it had found the sources, because I could do 'l httpsync.c:110' or
similar and see the sources. But doing 'l main' wouldn't work until I used
'-ggdb' instead of '-g'.

> If your problem seems to be one of those, try compiling with -gstabs+,
> as the FAQ suggests.

I tried (most of) the FAQ's suggestions - my first port of call ;) I
looked at the gcc, gdb docs too, which lead me to try '-ggdb'. I've tried
more switches since then (see below).

> Failing all that, describe here what commands did you use inside GDB
> and how exactly did they fail to produce the desired effect.

Invocation:
    gdb httpsync.exe
or: gdb httpsync
or: gdb httpsync -d=./

Commands:
    l main

This returned something like 'no line information for main'.

> It would be nice if you could post the source of the shortest complete
> program that fails in the same way, so that somebody could compile it
> and dig into this problem.

BTW this only seems to have happened since I upgraded to gcc 2.8.1. I've
haven't mixed object file formats betwwen gcc 2.8.0 & 2.8.1, because I've
recompiled libsocket with 2.8.1. I think I haven't noticed this before,
because I haven't done any debugging until now with gcc 2.8.1. Has the
default debug format changed between 2.8.0 & 2.8.1?

I now have problems setting breakpoints in libsocket (built with '-g'),
because that does not contain line info either according to gdb 4.16 :(

I thought this might be because I hadn't followed the instructions from
README.DJGPP that comes with gcc 2.8.1. However after removing
$DJDIR/lib/specs and $DJDIR/lib/djgpp.djl, I had the same problem.

Anyway, there's a test Makefile and testit.c below. From trying various
switches, it appears that gcc 2.8.1 is emitting debug info in COFF format.
So my solution is to use one of -gstabs, -gstabs+, -ggdb. -gstabs doesn't
use any gdb extensions, so I'll use that.

<Start Makefile>
# Makefile for testing out gcc/gdb debug switch interaction
# Written by Richard Dawe <richdawe AT bigfoot DOT com>

# Not supported by gcc 2.8.1
#DEBUGFLAGS = -gcoff+
#DEBUGFLAGS = -gxcoff
#DEBUGFLAGS = -gxcoff+
#DEBUGFLAGS = -gdwarf
#=> (not tried) DEBUGFLAGS = -gdwarf+

# These don't work
# -g = -g2
#DEBUGFLAGS = -g
#DEBUGFLAGS = -g3
#DEBUGFLAGS = -gcoff

# These work
#DEBUGFLAGS = -ggdb
DEBUGFLAGS = -gstabs
#DEBUGFLAGS = -gstabs+

CFLAGS  = $(DEBUGFLAGS) -Wall -Id:/develop/lsck/include
LDFLAGS = $(DEBUGFLAGS) -Ld:/develop/lsck/lib
LIBS    = -lsocket

testit: testit.o
        $(CC) $(LDFLAGS) -o $@ $< $(LIBS)

testit.o:       testit.c
        $(CC) $(CFLAGS) -c $<
</End Makefile>

<Start testit.c>
/* A minimal program that will cause libsocket to be linked in. */
#include <lsck/lsck.h>
int main (void) { __lsck_init(); return(0); }
</End testit.c>

testit.c should build with any version of libsocket after 0.7.0 (I think,
it's been so long since I worked on it :) ). __lsck_init() may need
replacing with lsck_init() in early versions of 0.7.x.

I didn't try a non-libsocket program, because I was trying to simulate
compilation of httpsync. I would hope that debugging would only depend on
the debugging format of the object format that you were looking at. If
this is not the case, I can try removing the __lsck_init() call sometime.

Thanks for the help. Bye,

-- 
--------------+----------------------+------------------------------------
 Richard Dawe | richdawe AT bigfoot DOT com | http://www.bigfoot.com/~richdawe/ 
--------------+----------------------+------------------------------------

- Raw text -