TIP: Click on subject to list as thread! ANSI
echo: 80xxx
to: JAMES VAHN
from: JERRY COFFIN
date: 1997-07-24 00:36:00
subject: sat.s (Linux-Asm)

On (22 Jul 97) James Vahn wrote to Jerry Coffin...
 JV> It's not as intuitive as Turbo Debugger, that's a fact.
Well, no, not quite.  In fact, not even close...
 JV> Even with the ugly info pages converted to HTML, things are still a
 JV> tad confusing. I was hoping to get a simple answer, like "press B"
 JV> or something, and have it load the source into an editor with a big
 JV> arrow pointing at the bug.
Hmm...perhaps I should lend you one of my Supertramp CDs.  They sound a
lot better than me singing "Dreamer...nothing but a dreamer!"
 JV> A hardcopy book on gdb would be great- the help screen is my only
 JV> savior at this point.
Well, if you had reasonable video board, I'd reccomend using xgdb and
displaying the help in another window at the same time, but if curses is
causing you problems, I doubt you want to even think of trying to get an
X server running.
 JV> What I get with 'gdb sat' is a message "No debugging symbols found"
 JV> I'm using gcc -E to preprocess sat.S into sat.s for the assembler,
 JV> then linking the object file with gcc. What happened to the symbols?
 JV>   gcc -E sat.S -o sat.s
 JV>   as sat.s -o sat.o
 JV>    gcc sat.o -o sat -lncurses
Hmmm...as?  or is that really gas?  In any case, ld certainly normally
puts debugging symbols in the executable by default, and you normally
have to specify --strip-all or --strip-debug to get rid of symbols.  You
_might_ want to try running ld directly instead of via gcc to see if you
get symbols that way - I s'pose your copy of gcc might have been setup
to leave symbols out for some reason or other.
 JV> Running the program under gdb produces a few complaints about the lack
 JV> of symbols, then
 JV>                         Segfault
 JV>                         0x4006bf7e in vfprintf ()
 JV> and since nowhere do I find a call to vfprintf in Jan's code, this
 JV> info is fairly useless to me.  :(
Hmm...if memory serves, gdb supports a `backtrace' (IIRC, can be
abbreviated to `bt') command to look at the callstack.  I believe you
can specify the number of calls it'll attempt to trace back; you'll
most likely want to specify a negative number, so it'll start at the
outermost call, and show, say, the first half dozen or so levels of
calls.  Most likely the call to vfprintf is hidden somewhere inside some
library code so his code is calling it indirectly.
I should warn you that while I've used gdb on a couple of different
systems, I haven't done it on Linux, so things _may_ be a bit different
for you.  Unless things are a lot different though, you should be able
to use `help stack' inside gdb to get information on the stack tracing
commands.
    Later,
    Jerry.
... The Universe is a figment of its own imagination.
--- PPoint 1.90
---------------
* Origin: Point Pointedly Pointless (1:128/166.5)

SOURCE: echomail via exec-pc

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.