🚀 go-pugleaf

Description of a gdb<-->gcc problem from Kimbo Mundy
----------------------------------------------------


The crux of the problem is that gdb doesn't always recognize when a .o
file has been compiled with gcc.  When this happens, one consequence
is that short parameters are mis-handled.

    Date: Sat, 17 Mar 90 21:28:54 EST
    From: kimbo
    To: prodvlp compilers reltools eng
    Subject: gcc/gdb problem

    The latest version of gdb has been having problems with some files
    compiled by gcc.  This usually manifested itself as reading the
    improper part of a word when a parameter was declared short.  It may
    have had other manifestations as well.

    The source of this problem was that the standard C compiler is sloppy
    about how it handles this kind of variable.  GCC is not, so the
    debugger has to distinguish between the 2.  (Note that this may also
    mean that dbx doesn't work right with gcc's .o files, but I have not
    checked this.)  To make this possible, gcc writes out a special symbol
    "gcc_compiled." at the front of the symbols in the .o file.  Gdb looks
    for this when reading a file's symbols.  Unfortunately, the Sun
    assembler was sometimes rearranging these symbols; this happens most
    often (but not always) when a module has static functions.  This made
    gdb think that files were compiled by Sun's cc when they were in fact
    compiled by gcc.

    To fix this, I have installed the GNU assembler (which does not mess
    with the order of its symbols) in /src/gnu/PORTS/sun3/gcc/as and in
    /usr/local/lib/gcc-as throughout the net.  This assembler will be
    prefered over /bin/as by gcc.  

    Note also that we do not have much experience with the GNU assembler.
    I have used it to assemble about 50 files, and the stuff seems to
    work fine so far, but you might want to beware.

Mark asked "How did you ever find this?":

    Date: Sun, 18 Mar 90 23:31:10 EST
    From: kimbo
    To: md@marvin
    Subject: gcc/gdb problem

    I was *very* lucky, it only took an hour or two.  I got involved with
    this when I was trying to find a crash and my short parameters were
    messed up.  Tomp had complained about this earlier in the week, so it
    seemed like it was worth looking at.

    I started by searching for "param" in gdb/dbxread.c.  That took me
    straight to the code that handles parameters.  I followed one red
    herring there for a while, but then I noticed that it handled
    "processing_gcc_compilation" differently than pcc compilations.  The
    real lucky thing was that I followed this to find where it was set.
    This was right above in dbxread.c, and it was pretty well described in
    the comments.  So I decided to see what our .o files looked like.

    They were messed up, so I thought gcc wasn't writing its symbols out
    correctly.  After a little messing with this, I found that it seemed
    to be right.  I checked this with "gcc -S", which confirmed that gcc
    was OK.  So I tried assembling the .s file, and things got messed up.
    I then looked in bin/dops symbol table to see how often this happened,
    and it was pretty often.  Finally, I thought of trying the GNU
    assembler.  That did the trick, so the rest was just putting all the
    pieces together.

    Looking back on it, I'm amazed that I didn't get sidetracked more.  I
    was really groping in the dark.  At least I knew what tools to use to
    get the info I needed (especially "nm -ap").

It might be useful to have a gdb "gcc-compiled" command (i.e., one you
could put in your .gdbinit) to tell gdb not to bother looking for the
gcc_compiled symbol, but to instead just "believe" that they are all
compiled with gdb.

Or at least document this somewhere, that certain assemblers will
break this gcc_compiled trick.