Linux debug

[lukus001]

Hi all,

I have a program I want to debug to check that it is running as intended ~ it's not a 'finished' application so it will fail regardless, so it's just a matter of checking the current code before adding more ontop before it becomes unmanagable.

I have GDB but by no means do I know how to use it properly.  I've simply been using 'run' with no advance features and GDB's documention doesn't seem to be the most straight forward thing to read

What i would like to do is step through each line of code, or several instructions at a time and see the results.   I understand GDB does have a 'steppping' feature, but it will complain about my program not running so then I type "run" to which it runs the program, reaches a fault /end of program and 'step' still doesn't work becuase the program has already ended?

I would also like to be able to get as much information out as possible, which I suspect is gdb's TUI feature, but it appears to be only showing the source window for me... Not sure if this is because I'm using it on a SSH client to make things more complicated :|

Any help appreciated.

[Frank Kotler]

Hi Lukus,

Yeah... I consider gdb "unfriendly". There are alternatives, but learning to use gdb is probably worthwhile(?). Try something like...

Code: [Select]

global _start

section .text
_start:

nop   ; "parking place for gdb"
break_here:
; your code


Assemble it with "nasm -f elf -F dwarf myfile.asm". Don't use the "-s" switch to ld (if you're in that habit). Load 'er up in gdb, and first thing, do "break break_here". Then "run", and it should stop and let you step through it. If it doesn't work.... told ya it was unfriendly! (oh yeah, put a nop after each int 80h, too)

I've written a good deal more about this... but I can't remember where - AsmCommunity board maybe? I'll look. I posted (as I recall) links to some "tutorials" demonstrating the use of gdb to find bugs. Possibly some documentation, too...

One of the things that gdb will do is to find and read ".gdbinit", either in home directory or current directory (I think). You can configure gdb to be more "Nasm friendly". Chuck Crayne posted his .gdbinit, shortly before he passed away. It included support for 64-bit gdb! I'm positive I saved it. 100% certain! But I can't find it at the moment. Here's one I got from Jeff Owens (attached).

This deserves a better answer... maybe I'll be back...

Best,
Frank

[Frank Kotler]

This is the bit from the AsmCommunity board...

http://linuxfocus.berlios.de/English/July2004/article343.shtml

http://www.ffnn.nl/pages/articles/linux/gdb-gnu-debugger-intro.php

http://www.ibm.com/developerworks/linux/library/l-debug/

http://www.ibm.com/developerworks/library/l-gdb/

Best,
Frank

[lukus001]

Hi frank,
Thank you very much once again.

I did '-F stabs' ~ thought I was using dwarf before but forgot which one I used, Is Dwarf the correct one to be using?.

I also used "break" but with a line number instead, I just tried it with "break 10" and it's letting me step through now with next! Guess I was wrong to do "break 1" which seems to make the whole program run from start to finish, probably because there is no code there just the .text section declaration !opps.

Is a 'nop' after a 80h interrupt to give gdb a pause to latch onto?

I've also managed to debug my code and find an error and fix it   Its funny how an example on the internet, written in assembly is wrong :<

Reading the links now,
Many thanks,
Luke.

[dsdarrow]

Hi;
I'm not really a programmer (especially not a nasm programmer!) what I am is mostly a 'dabbler'. But I can read the manual, even if I don't understand all that it tells me and what I find there is this:

2.1.12 The ?g Option: Enabling Debug Information.
       This option can be used to generate debugging information in the specified format. See section 2.1.11. Using
       ?g without ?F results in emitting debug info in the default format, if any, for the selected output format. If no
       debug information is currently implemented in the selected output format, ?g is silently ignored.

so the place to start is determening what format your debugger will use. This you'll find in the docs for your debugger. And then find out what nasm can and will output for the type of file you're wanting to debug.

Another listing from the nasm manual gives me this info:

2.1.11 The ?F Option: Selecting a Debug Information Format
       This option is used to select the format of the debug information emitted into the output file, to be used by a
       debugger (or will be). Prior to version 2.03.01, the use of this switch did not enable output of the selected
       debug info format. Use ?g, see section 2.1.12, to enable output. Versions 2.03.01 and later automatically
       enable ?g if ?F is specified.
       A complete list of the available debug file formats for an output format can be seen by issuing the command
       nasm ?f <format> ?y. Not all output formats currently support debugging output. See section 2.1.26.
       This should not be confused with the ?f dbg output format option which is not built into NASM by default.
       For information on how to enable it when building from the sources, see section 7.14.
 So, if I'm building a standard elf executible I can do this:

Command prompt$ nasm -f elf -y

valid debug formats for 'elf' output format are ('*' denotes default):
    dwarf     ELF32 (i386) dwarf debug format for Linux/Unix
  * stabs     ELF32 (i386) stabs debug format for Linux/Unix


 

[dsdarrow]

Sorry. I pushed the wrong button somewhere. What the previous post was Going to say is;

We know that gdb will work with stabs and that's the default output when we just use the -g switch. So that doesn't work for you so you can _try_ some other solutions. One was to use Dwarf instead of Stabs. To do that you have to ad the -F <format> switch. Note that's a uppercase -F dwarf. So your command line would then be 'nasm -f elf -g -F dwarf -o yourfile.o yourfile.asm'

Dwarf will work for gdb also. I know, I just tried it. But Frank gave a couple other suggestions. One was to put a nop after _start.
that's on the line after you actually start executing; like this

global _start   ; not here!

section .text
_start:
       nop   ; HERE after the _start label begins execution

and I'll give another suggestion; instead of using break 10 on the command line for gdb, load the program in gdb then just type l (that's an ell not a one) and it will list the source for you. AND give you the line numbers. then type break (the line number of the nop). THEN tell gdb to RUN and it'll stop at that nop and you can single step from there.

And finally, you can even put and int3 instruction on the line after nop. int3 a software break. It requires no arguments just the single int3. That's the exact instruction that gdb uses to break at a certain point. int3 is almost guaranteed to stop your program whenever it's encountered. So don't forget to remove that int3 when you are done debugging. BTW, int3 is a good way to start debugging a program that starts but then crashes. If you've got some idea where the problem is, just put an int3 AHEAD of that point, recompile and run the prog. If it starts but then just stops with and in3 error, the problem is after that point in the code. move the int3 further down, recompile and run it again. If it crashes before stopping for int3, you know the error is somewhere between those two point.

Hope that helps ya
Doug

[Frank Kotler]

Great rundown, thanks Doug! You've discovered a minor glitch in the manual... "-f dbg" *is* compiled into Nasm (didn't used to be... I'm pretty sure). It's useful for debugging Nasm, not your program, so it isn't "interesting", but it is there.

As I said, I think the best thing is to gird up our loins and learn to use gdb. But I've been meaning to get up a list of alternatives. A list of "front ends" to gdb would be good, too. "ddd", I think, and "insight"(?)... more(?). I don't know much about them (I'm a "command line guy", pretty much).

Jeff Owens has got a package of tools...

http://www.linuxasmtools.net/

Among many other neat things are two debuggers: "asmbug" is messing up my console right now - I think it's supposed to be run from an xterm, maybe. "minibug" seems to work good - simple to use... more colorful than debug.

I think the gem of Jeff's package is his "asmref". The most "asm friendly" description of the system calls I've seen. Indexed by name, number, type - example code(!!!)... Kernel errors, symbols, structures, signals... it hooks into Nasm documentation - including the instruction set reference from the "old" manual... and another x86 instruction set reference... plus documentation of Jeff's own considerable suite of programs (I'd forgotten "asmsrc" - intended to generate Nasm-compatible source from an executable - must look at that again!). Plus documentation for his library - oh yeah, it includes a library - libraries, I should say - one for X, too!

For some reason, I don't use Jeff's stuff much. I don't know why. So I don't give him as much feedback and encouragement as I should. He's put a lot of work into this, and I don't think too many people are using it. Definitely worth a look! Anyway, to the topic - "minibug" might be a good debugger for beginners.

I frequently use Patrick Alken's "ald" - the assembly language debugger. It is, as the name suggests, asm friendly.

http://ald.sourceforge.net/

There's an offshoot of ald, by Terry Loveall, which pastes in some Nasm code to give ald assembly capabilities (whee! just like DEBUG!). Since it seems to have vanished from the web(?)...

http://home.myfairpoint.net/fbkotler/debug-0.0.21.tgz
(you may have to hold down left-shift to get that to download, rather than "print" - the latter is not informative!

The last one, I don't recall where I found. Comes from Taiwan. Although the source files are named ".s", they're in Nasm syntax(!). Apparently intended to be a kernel debugger(?), it squawks about a kernel module not being insmod'ed. If I try that, it squawks about wrong version. Changing just the version string, reassembling, and insmod'ing results in a prompt reboot. Obviously, I've got a lot to learn about kernel modules! But if you ignore the error message, it seems to work much like DEBUG. Other interesting program with it... "kernsym" - I don't know what to make of it. Interesting mostly in that it's in Nasm syntax (like Jeff's minibug and asmbug), rather than as something a beginner might want to debug his program...

http://home.myfairpoint.net/fbkotler/debug-0.3.zip

Those are the alternatives I can think of. I'd say give "minibug" a shot, if you don't feel like matching wits with gdb...

Best,
Frank

[dsdarrow]

Hi, Frank;

Thanks for the compliment. As I said in my post (I think I said it) I'm just a dabbler. And just learning too. It's just that I had just been through all that trying to figure what I needed to link with what to get something to assemble and debug. Every thing Lukus was asking I'd just tried and finally succeeded. So it was easy to tell him. He (and others on a board named "Beginners Questions") might benefit from hearing from it another beginner. I hope it helped him.  And others that will that will have to go down that same road sooner or later.

But I gotta say that you do a great job yourself. You put a great deal into your posts. I don't know how you even have the time. Good job, Frank.

Another gdb front end is Nemiver. It's made with tk. And another debugger is fdbg. From the guy who wrote fasm. But I think you're right about GDB. I just haven't got around to it yet. I spend enough time learning nasm.

bye
Doug

[lukus001]

Thanks for the replies.

dsdarrow,

As per the debug types, I'm aware of what both Nasm and gdb will accept both stabs and dwarf, however I was wondering if there was any perticular benifit of using Dwarf over stabs (which happens to be Nasm defult)

Frank,

Been to linuxasmtool.net a few times before and only just noticed his debugging tools since you mentioned it! will be downloading it in a few minutes, seems like it'll do what i want perfectly.

Among my searches before I even heard of GDB "ald" sounded like a perfect contender so I fired up my SSH, typed "apt-get install ald" and debian doesnt have it ! .  Tried to install it from source but think there were far to many errors stopping me from installing which is a shame.

I must admit (and it is mentioned in one of the links you gave me) strace is a wonderful tool to debug with.  I was doing some socket programming and even though bind would work i.e. it returned 0 to signal bind was done sucesfully strace clearly showed it was wrong

GDB while i can step through my program now I still got a fair bit to learn to get a bit more informative information.  Hopefully linuxasmtools will be what i need with less the head ache

Many thanks,
Luke.

[dsdarrow]

Hi, Lucus;

Don't really know whats different in the two. I just know, for me, stabs hangs if it runs into a lib or even just an external assembled file. Dwarf will often run on through and even give some info back. And stabs won't work at all with most of the integrated debuggers (like codeblocks, eclips) but will with dwarf. I'm no expert on any of this, I just know what I've found that will work for me.

[Frank Kotler]

I was just informed about another debugger...

http://www.codef00.com/projects.php

I haven't tried it - wants "packages" I haven't got - but it looks "Ollydbg-like". I suspect some people will like it!

Best,
Frank