Help w/ gdb

Help w/ gdb

[Sean Chitwood]

Hi-
	I periodically ask this question here because I have never found a more appropriate audience or satisfactory answer.

	I am attempting to help w/ the mozilla project, but I am having little success due to the following problem. When I attempt to debug an assert/crash as I bring up the stack trace I notice that some of the frames point only to the ending curly brace of a function (Not always the one it says is being debugged). I cannot examine variables, or learn anything else productive about the situation. I realize I am not familiar w/ gdb, I am primarily familiar w/ windows GUI based debuggers, so I figure I am missing a configuration setting, but for the life of me I can't figure out what it is. I do know that I am keeping the source and binary files synced, so that shouldn't be it. It seems to load the symbols correctly (no complaining about missing symbols), butother than that I seem to be clueless.

	I am enclosing my .gdbinit file (it is short) so you can see if anything is missing. I am using gdb-4.18-4c, which I believe I got from fsirl's directory on devel.linuxppc.org.

	So please could you help?

	Sean aka Darkmane
+------------------------------
+ On October 16, 1999 A.D.
+ Sean Chitwood proudly proclaimed
+ his love for Melissa Webb
+ and made her his lifemate
+------------------------------

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Help w/ gdb

[Kevin Buettner]

On Jan 15, 11:12pm, Sean Chitwood wrote:

> I periodically ask this question here because I have never found a
> more appropriate audience or satisfactory answer.
> 
> I am attempting to help w/ the mozilla project, but I am having
> little success due to the following problem.  When I attempt to
> debug an assert/crash as I bring up the stack trace I notice that
> some of the frames point only to the ending curly brace of a
> function (Not always the one it says is being debugged).  I cannot
> examine variables, or learn anything else productive about the
> situation.  I realize I am not familiar w/ gdb, I am primarily
> familiar w/ windows GUI based debuggers, so I figure I am missing a
> configuration setting, but for the life of me I can't figure out
> what it is.  I do know that I am keeping the source and binary files
> synced, so that shouldn't be it.  It seems to load the symbols
> correctly (no complaining about missing symbols), butother than that
> I seem to be clueless.

I think this is a bug in either the linker or in gdb itself.  (If it's
the bug I'm thinking of, the bug is actually in the linker, but is
more easily worked around in gdb.) Get the gdb sources and take a look
at config/powerpc/tm-linux.h.  Now search for the line

#define SOFUN_ADDRESS_MAYBE_MISSING

Is it there?  (I'm guessing not.) Try adding the above line to
tm-linux.h and then rebuild gdb.

Let me know if it fixes your problem.

Thanks,

Kevin

-- 
Kevin Buettner
kev@primenet.com, kevinb@cygnus.com

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Help w/ gdb

[D.J. Barrow]

It helps gdb a lot not to compile with optimisation.
e.g. compiling -g -O2 on powerpc stops gcc copying
parameters passed in registers onto the stack
to aid debugging, this results in stack traces &
viewing passed in parameters frequently being rubbish.

Mind you in a project as large as mosizza there may be
inline functions which gcc may refuse to compile
without optimisation.
In short if you can compile for debugging without
using -O2 do so or at least try to compile all the
code
of intrest without the -O2 flag.


--- Kevin Buettner <kev@primenet.com> wrote:
> 
> On Jan 15, 11:12pm, Sean Chitwood wrote:
> 
> > I periodically ask this question here because I
> have never found a
> > more appropriate audience or satisfactory answer.
> > 
> > I am attempting to help w/ the mozilla project,
> but I am having
> > little success due to the following problem.  When
> I attempt to
> > debug an assert/crash as I bring up the stack
> trace I notice that
> > some of the frames point only to the ending curly
> brace of a
> > function (Not always the one it says is being
> debugged).  I cannot
> > examine variables, or learn anything else
> productive about the
> > situation.  I realize I am not familiar w/ gdb, I
> am primarily
> > familiar w/ windows GUI based debuggers, so I
> figure I am missing a
> > configuration setting, but for the life of me I
> can't figure out
> > what it is.  I do know that I am keeping the
> source and binary files
> > synced, so that shouldn't be it.  It seems to load
> the symbols
> > correctly (no complaining about missing symbols),
> butother than that
> > I seem to be clueless.
> 
> I think this is a bug in either the linker or in gdb
> itself.  (If it's
> the bug I'm thinking of, the bug is actually in the
> linker, but is
> more easily worked around in gdb.) Get the gdb
> sources and take a look
> at config/powerpc/tm-linux.h.  Now search for the
> line
> 
> #define SOFUN_ADDRESS_MAYBE_MISSING
> 
> Is it there?  (I'm guessing not.) Try adding the
> above line to
> tm-linux.h and then rebuild gdb.
> 
> Let me know if it fixes your problem.
> 
> Thanks,
> 
> Kevin
> 
> -- 
> Kevin Buettner
> kev@primenet.com, kevinb@cygnus.com
> 
> 

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Help w/ gdb

[Sean Chitwood]

On Sun, 16 Jan 2000, Kevin Buettner wrote:

> #define SOFUN_ADDRESS_MAYBE_MISSING
> 
> Is it there?  (I'm guessing not.) Try adding the above line to
> tm-linux.h and then rebuild gdb.
> 

	It was not there, but that did not fix my problem. I guess this might be the problem w/ optimization. 

	Damn.....

	Sean aka Darkmane
+------------------------------
+ On October 16, 1999 A.D.
+ Sean Chitwood proudly proclaimed
+ his love for Melissa Webb
+ and made her his lifemate
+------------------------------


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Help w/ gdb

[Sean Chitwood]

Ok, I'm assuming you mean to change the CFLAGS in the Makefile... correct? I'll do that tonight and hopefully let you know in th emorning....

	Just for my edification, what is the difference between -g and -gdwarf-2... I have a bad feeling one produces elf binaries and one produces dwarf binaries.... Not that I would know the difference...


On Mon, 17 Jan 2000, Kevin Buettner wrote:

> One of the things you might try is to recompile using DWARF2 debugging
> symbols.  Replace -g with -gdwarf-2.
> 
> I'm not necessarily suggesting that you start use dwarf2 debugging
> symbols instead of stabs, but this will tell me more about the
> problem.  (If it works properly with dwarf2, then I have a patch for
> you which should make it behave properly with stabs.)
> 
> Thanks for the feedback.
> 
> Kevin
> 
> 

	Sean aka Darkmane
+------------------------------
+ On October 16, 1999 A.D.
+ Sean Chitwood proudly proclaimed
+ his love for Melissa Webb
+ and made her his lifemate
+------------------------------


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Help w/ gdb

[Kevin Buettner]

On Jan 17,  4:40pm, Sean Chitwood wrote:

> Ok, I'm assuming you mean to change the CFLAGS in the Makefile... 
> correct?  I'll do that tonight and hopefully let you know in th
> emorning....

Yes.  (Or whatever variable your Makefile uses to set the -g debugging
flag for the compiler.)

BTW, make sure you specify it as -gdwarf-2 and NOT -gdwarf2.  Oddly
enough, these mean completely different things.  (The former says to
use the DWARF2 format while the latter says to use the DWARF format at
debugging level 2.)

> Just for my edification, what is the difference between -g and
> -gdwarf-2...  I have a bad feeling one produces elf binaries and one
> produces dwarf binaries....  Not that I would know the difference...

ELF binaries are created in both instances.  It's the debugging format
which will be different.  Many platforms use the stabs debugging
format by default -- I think this is the default format for linux/ppc. 
You can explicitly use a different format by using one of the other
-g switches.  (-gstabs, -gstabs+, -gdwarf, -gdwarf+, ...)

To be quite honest with you, I haven't checked recently to see which
debug format linux/ppc uses by default or even if DWARF2 will work at
all.  But it is something to try.  Even if DWARF2 isn't completely
satisfactory for debugging (e.g, it could generate outrageously large
symbolic information), if it addresses the specific problem that you
reported, it'll let me know if it's worth it for you to try a patch
which does a better job of resolving zero-valued N_FUN symbols for the
stabs format.

I noted in another message that there's a patch at the end of

    http://sourceware.cygnus.com/ml/gdb/1999-q3/msg00325.html

that you could try, but I doubt that it will apply cleanly.  (I think
I have one that should apply cleanly though.  But before I send it to
you, I'd like to know the results of your DWARF2 tests.)

Kevin

-- 
Kevin Buettner
kev@primenet.com, kevinb@cygnus.com

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Help w/ gdb

[Pierre Sarrazin]

I read the "Help w/ gdb" thread and I have found that one of the
proposed solutions solves one problem that I had on LinuxPPC R5:
I recompiled my small example program with -gdwarf-2 (and gcc 2.95.2)
instead of just -g and then I was able to step into the shared library
function call correctly.

Kevin Buettner, suggested this fix last month in
http://lists.linuxppc.org/listarcs/linuxppc-dev/200001/msg00245.html


However, the problem persists in a different form when I try the
fix with a larger program and larger library (compiled with gcc 2.95.2
with -fPIC and -gdwarf-2). In gdb, I want to step into the statement

  return ((int (*) (void)) functionPtrs[0])();

and I end up with this:

0xfd1859c in InitInterfaceCorrection ()
    at
/usr/local/lib/gcc-lib/powerpc-unknown-linux-gnu/2.95.2/../../../../include/g++-3/stl_alloc.h:518
518             return(_S_chunk_alloc(__size, __nobjs));

If I then give the "next" command, the program continues until it exits.
InitInterfaceCorrection() is the correct function name. Its first
statement is:

  int error = InitInterfaceCorrection_X(NULL, NULL);


Here is the bug report I sent to the GDB mailing list on 21 Jan 2000,
which includes the example program. Note however that since then I
have upgraded to gcc/g++ 2.95.2.

I am still using gdb 4.17.0.11 (which came with LinuxPPC R5).

===========================================================================

GDB does not step correctly into a runtime-loaded function under
LinuxPPC R5. The problem does not occur under RedHat 5.2 on a Pentium.

The Power Macintosh has the following characterics:
- kernel 2.2.6-15apmac #1 Mon May 31 03:54:09 EDT 1999
- /lib/libc-2.1.1.so
- GNU gdb 4.17.0.11
- gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release)

Here is the main program (prog.c):

---------------------------------------------------------------------------
#include <assert.h>
#include <stddef.h>
#include <dlfcn.h>

int main(int argc, char *argv[])
{
        void *handle;
        void (*function)(void);

        handle = dlopen("./libfoo.so", RTLD_NOW);
        assert(handle != NULL);
        function = dlsym(handle, "library_function");
        assert(dlerror() == NULL && function != NULL);

        (*function)();

        dlclose(handle);
        return 0;
}
---------------------------------------------------------------------------


Here is the library source file (libfoo.c):

---------------------------------------------------------------------------
#include <stdio.h>

void library_function(void)
{
        printf("This is library_function()\n");
        printf("--------------------------\n");
}
---------------------------------------------------------------------------


Here is the Makefile:

---------------------------------------------------------------------------
CFLAGS=-fPIC -g -Wall

all: libfoo.so prog

libfoo.so: libfoo.o
        gcc -shared libfoo.o -o libfoo.so

libfoo.o: libfoo.c
        gcc $(CFLAGS) -c libfoo.c

prog: prog.o
        gcc -rdynamic -o prog prog.o -ldl

prog.o: prog.c
        gcc $(CFLAGS) -c prog.c

clean:
        rm -f prog lib*.so *.o core
---------------------------------------------------------------------------


The program executes fine by itself, as well as in GDB without
breakpoints.

Here is the scenario.  I enter GDB and set a breakpoint on this line
of prog.c:

        (*function)();

Then I run the program and GDB stops on that line. I give the "step"
command and get this:

---------------------------------------------------------------------------
(gdb) break 15
Breakpoint 1 at 0x1800734: file prog.c, line 15.
(gdb) run
Starting program: /home/sarrazip/pgm/bug-gdb-dll/prog

Breakpoint 1, main (argc=1, argv=0x7ffffbd4) at prog.c:15
15              (*function)();
(gdb) step
0x161a61c in library_function () at libfoo.c:7
7       }
(gdb) next
This is library_function()
--------------------------
main (argc=1, argv=0x7ffffbd4) at prog.c:17
17              dlclose(handle);
(gdb)
---------------------------------------------------------------------------


On a Pentium machine running RedHat Linux 5.2, the "step" works fine:
it stops on line 5 of libfoo.c, i.e., the first printf() statement.
This Pentium machine has the following characteristics:
- kernel 2.0.36 #1 Tue Oct 13 22:17:11 EDT 1998
- /lib/libc-2.0.7.so
- GNU gdb 4.17.0.4
- gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release)

--
Pierre Sarrazin <sarrazip@machinasapiens.com>

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Help w/ gdb

[Kevin Buettner]

On Feb 16,  2:11pm, Pierre Sarrazin wrote:

> However, the problem persists in a different form when I try the
> fix with a larger program and larger library (compiled with gcc 2.95.2
> with -fPIC and -gdwarf-2).

Pierre,

Thanks for the report.

It is quite timely because this week I'm working on integrating
linux/ppc support into the gdb cvs repository at
sourceware.cygnus.com.

I'll try your example program once I get farther along.

Thanks again,

Kevin

--
Kevin Buettner
kev@primenet.com, kevinb@redhat.com

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Help w/ gdb

[Kevin Buettner]

On Feb 16,  2:11pm, Pierre Sarrazin wrote:

[lots of stuff snipped]
> The program executes fine by itself, as well as in GDB without
> breakpoints.
>
> Here is the scenario.  I enter GDB and set a breakpoint on this line
> of prog.c:
>
>         (*function)();
>
> Then I run the program and GDB stops on that line. I give the "step"
> command and get this:
>
> ---------------------------------------------------------------------------
> (gdb) break 15
> Breakpoint 1 at 0x1800734: file prog.c, line 15.
> (gdb) run
> Starting program: /home/sarrazip/pgm/bug-gdb-dll/prog
>
> Breakpoint 1, main (argc=1, argv=0x7ffffbd4) at prog.c:15
> 15              (*function)();
> (gdb) step
> 0x161a61c in library_function () at libfoo.c:7
> 7       }
> (gdb) next
> This is library_function()
> --------------------------
> main (argc=1, argv=0x7ffffbd4) at prog.c:17
> 17              dlclose(handle);
> (gdb)
> ---------------------------------------------------------------------------

Pierre,

Thanks for including the program and detailed bug report.  I mentioned in
earlier email that I was merging the patches for linux/ppc gdb into the
current sourcebase.  I am happy to report that this merge is complete and
that the source may be downloaded from the sourceware site.  See

    http://sourceware.cygnus.com/gdb

for more information.  Franz Sirl has also created an RPM from sources
earlier in the week and placed it in

    ftp://devel.linuxppc.org/users/fsirl/

(I'm not sure if his sources contain my most recent shared library fixes
though.)

Anyway, when I run your program, I'm now seeing the following
(correct, I believe) output:

    GNU gdb 20000204
    Copyright 1998 Free Software Foundation, Inc.
    GDB is free software, covered by the GNU General Public License, and you are
    welcome to change it and/or distribute copies of it under certain conditions.
    Type "show copying" to see the conditions.
    There is absolutely no warranty for GDB.  Type "show warranty" for details.
    This GDB was configured as "powerpc-unknown-linux-gnu"...
    (gdb) b 15
    Breakpoint 1 at 0x1800734: file prog.c, line 15.
    (gdb) r
    Starting program: /home/kev/ctests/pierre/prog

    Breakpoint 1, main (argc=1, argv=0x7ffffd54) at prog.c:15
    15              (*function)();
    (gdb) s
    library_function () at libfoo.c:5
    5               printf("This is library_function()\n");
    (gdb) next
    This is library_function()
    6               printf("--------------------------\n");
    (gdb) next
    --------------------------
    7       }
    (gdb) next
    main (argc=1, argv=0x7ffffd54) at prog.c:17
    17              dlclose(handle);

Kevin

--
Kevin Buettner
kev@primenet.com, kevinb@redhat.com

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Help w/ gdb

[Kevin Buettner]

On Jan 15, 11:12pm, Sean Chitwood wrote:

[Regarding gdb...]

> When I attempt to debug an assert/crash as I bring up the stack
> trace I notice that some of the frames point only to the ending
> curly brace of a function (Not always the one it says is being
> debugged).  I cannot examine variables, or learn anything else
> productive about the situation.

I had sent some earlier replies to Sean suggesting a couple of
workarounds.  These workarounds should no longer be necessary if you
build gdb with the current development sources from
sourceware.cygnus.com.

See http://sourceware.cygnus.com/gdb for more information on how to
download these sources.  (If you're going to download via ftp, you'll
want to wait for next week's snapshot as it will contain several
shared library fixes.)

Kevin

--
Kevin Buettner
kev@primenet.com, kevinb@redhat.com

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/