🚀 go-pugleaf

This is not a bug report, just a question about a detail of the
internals of GDB.

I am running GDB (4.5, but that's irrelevant, I think) under SCO UNIX on
a DECpc workstation, and I'm having trouble interpreting the behavior
GDB displays when offered a program which is linked from an object file with 
errors in the symbol table.

What does it mean when GDB loses track of the line number and starts
displaying addresses instead of lines?  

I am trying to correct the symbol table output of a compiler, and
thought that running GDB on the output would reveal the whereabouts of
any errors.  I think that it did tell me where an error lies, but I am
a bit perplexed about the way it responds to the error.

When encountering a label in the program, GDB stops telling me where 
in the source code I am, and just says that I am at 
"0x175 in [label] (1)".  The bug is hardly in GDB, but rather in
my COFF symbol table.  (Note however, that the bug only shows itself
when the program is being debugged --- the program itself does exactly
what it should.  But of course, if the debug option to the compiler shall
be of any use, the debugging info that it lays out must be correct.)
Here is what happens when I run GDB on a test program:

(gdb) s
41              d := c;
(gdb) l
39              b := a;
40              c := b;
41              d := c;
42              blokk:
43              BEGIN
(gdb) s
0x175 in blokk (1)
(gdb) inf fra
Stack level 0, frame at 0x7ffff860:
 eip = 0x175 in l_enkeldekl (l_enkeldekl:46); saved eip 0x12d
 called by frame at 0x7ffff870
 source language unknown.
 Arglist at 0x7ffff860, 1 arg: 1
 Locals at 0x7ffff860, Previous frame's sp is 0x0
 Saved registers:
  ebp at 0x7ffff860, eip at 0x7ffff864
(gdb) inf lin *0x175
Line 46 of "l_enkeldekl" starts at pc 0x175 and ends at 0x17e.
(gdb) f
#0  0x175 in blokk (1)
(gdb) 

As you can see, GDB in fact knows exactly which line number it is at
(namely 46 in this case), but to see the contents of that line I must
ask for it explicitly, which is very cumbersome.  In Emacs, the arrow
in the source buffer stays on line 41 and doesn't move even after a
"frame" command.  When the stack is either pushed or popped, every-
thing is back to normal, but for the duration of the topmost frame 
GDB prefers to present me with hex offsets (eip values) instead of
line numbers.  Because of wrong layout in the symbol table, labels
attached to ".bb" assembler directives are treated a little too much
like function calls, I think.  Incidentally, if the label is removed
from the program, GDB runs perfectly on it, and every line is
displayed the way it should.

I assume that the part of GDB which displays the current line or the 
arrow (under Emacs) somehow retrieves its line number info elsewhence than
e.g. the "info frame" command.  I further assume that it fails to
find the current line number but at least knows the value of the
instruction pointer.  It does not manage, however, to automatically
translate this into a line number and use that as the current line,
although if you type "info line *0x175" it promptly tells you that
this of course is line 46.

I will simply change my compiler so it doesn't output the labels (into
the text section of the symbol table) when compiled with the debug
option, and everything should be fine again.  (I can do this because
this kind of labels are not terribly important in my language --- they
only affect the scope of variables.)  I just don't understand why the
effect of the error is what it is.

I do believe that the "line number entries" parts of my .o-files are
correct.  (Doesn't the fact that "info frame" displays the correct
line number together with the correct instruction pointer confirm
this?)  Also, the frame address never changes when the line numbers
"disappear" from GDB.  The setting of "complaints" and "verbose" gives
no additional information in the above example.  So what is it then
that changes when a label is encountered?  That is what I don't know.

I'd appreciate it if someone who knows how GDB works would mail me and
explain to me why the appearance of a label symbol (n_scnum=1, n_sclass=0, 
n_numaux=0, _u_name=blokk) should have such a strange effect.  (Maybe
to you it isn't strange at all?)  In particular: Could this mean that
there is something wrong in the line number table as well, or can the
one extra symbol in the symbol table explain the behavior of GDB?
Would it make a difference if I moved the symbol elsewhere in the
symbol table?  Is this a FAQ?  Am I overlooking something terribly obvious?
I guess I don't expect any answers to this type of obscure questions...

Ulf Lunde