nasm 2.10

[nerome]

Hello everyone,

I have some trouble using nasm 2.10 with the insight debugger. Prior to revision 2.03 I could run "insight program" and insight would show the assembler code (intel syntax) and I could just set some break points and debug. If I use nasm 2.10 insight will only show the binary disassembly in AT&T syntax. Has any one here seen this behavior or knows a solution to this problem?

Kind regards & thanks,
ner0

[Frank Kotler]

I'm not familiar with Insight.  A front end for gdb, isn't it? I think the command to get gdb to use Intel syntax is "disassembly-flavor=intel" or similar. gdb is happier if you put "-F dwarf" on Nasm's command line. I suspect that something has changed besides your Nasm version. There have been changes since 2.03, but I can't think of anything that would account for this. If you can't get it, show us your command line for Nasm and ld/gcc.

Best,
Frank

[nerome]

Hello Frank,

thanks for your reply  .

I fear that insight is more like a branch of GDB instead of a clean front end that is just invoking the cmd version of GDB. I invoke nasm, ld and insight like this on a 32bit system:

Code: [Select]

nasm -t -f elf -F stabs sandbox.asm -l sandbox.lst
ld -o sandbox sandbox.o
insight sandbox

It seems not to matter whether I select stabs or dwarf as debugging data fromat. I think prior to version 2.03 insight wasn't actually showing the disassembly but the actual .asm file where you could set breakpoints much like debugging a c program. With binaries created from obj files with nasm > 2.03 insight will only show the disassembly.

Kind regards,
Nerome

[dogman]

Are you using the examples from Duntemann? What version of Insight and which version of gdb are you using?

[nerome]

Hello Dogman,

exactly. I have tried GDB/Insight 6.8-1 and the latest developement version. Both are behaving the same way, binaries from nasm < 2.03 are working but not for newer versions.

Kind regards,
nerome

[dogman]

Ok Nerome, I have the book and code and I have a recently-built copy of insight and a recent stable nasm. Please tell me which example you're testing and I will check also. Don't use the "stable" insight. The Red Hat developers always say the stable insight version is not very good and gdb 6x is very old.

[nerome]

Hey Dogman,

it actually doesn't matter what example I use it is for all binaries created with a new version of nasm (2.10) e.g.:

Code: [Select]

section .data

SomeString: db "I'm a noob...", 10
SomeStringLen: equ $-SomeString
SecondString: db "well not such a noob..",10
SecondStringLen equ $-SecondString

section .text

global _start

_start:
nop
mov eax,4 ; prepare to call sys_write
mov ebx,1 ; write to stdout
mov ecx,SomeString ; load start address of string to display
mov edx,SomeStringLen ; load length
int 80h   ; call int

mov eax,4
mov ebx,1
mov ecx,SecondString
mov edx,SecondStringLen
int 80h

;; correctly terminate program
mov eax,1
mov ebx,0
int 80h

nop
section .bss

Kind regards,
nerome

[dogman]

Ok, I am testing with nasm 2.10.04 compiled on Aug 20 2012 and I get the same results as you when stabs are used. It appears nasm doesn't create debugging symbols for either -g or -g -F stabs. All I see is objdump knows how to relate the address to a line of source but that doesn't seem to be enough for gdb to show you the source. Neither insight nor Netbeans (see following post) nor Intel idb show the source. Or, it could be newish copies of objdump and gdb don't look at stabs anymore. But dwarf does work here.

If I assemble and link with this command

Code: [Select]

nasm -g -o test.o test.s
ld -o test test.o

Then

Code: [Select]

objdump -g test shows me there are no debugging symbols.

If I assemble and link

Code: [Select]

nasm -g -F stabs -o test.o test.s
ld -o test test.o

I get the same results- no debugging symbols in the executable.

However, if I use If I assemble and link

Code: [Select]

nasm -g -F dwarf -o test.o test.s
ld -o test test.o

Then objdump -g shows me debugging symbols and insight CVS (gdb 7.6.50.20130703-cvs) shows the source and works ok if you choose MIXED in the pull-down box on the right side of the screen.

Edit: just for fun I downloaded nasm 2.03.01 and tried it. The results are the same. -g and -g -F stabs don't produce any debugging info according to objdump aside from just matching the source line to the address which again doesn't seem to be enough for gdb. So I downloaded 2.02 since you said "prior to 2.03" but I still get the same results. No debugging symbols according to objdump for either -g or -g F stabs. So I don't know whether objdump and gdb no longer recognize stabs (but I'm going to search) or whether you didn't remember something right.

[dogman]

Not that I am a huge fan of Java but if you have an extra gig or so of RAM lying around that you have no use for you can actually use Netbeans as a nasm IDE (yeah, I know, it's horrible overkill and against everything we believe in) and then use Netbeans' gui front end to gdb which is actually very nice. Really, all the gui front-ends to gdb I have seen on UNIX range from clumsy to horrible except Intel's which is really great. So I use that or I work on Solaris so I can use dbxtool standalone GUI to dbx or Solaris Studio which is also really nice. Netbeans is a good choice since it runs everywhere Java runs and gdb runs everywhere gdb runs so it's just easier than dealing with all the horrible quirks of addons etc. Food for thought... The idea of running a Java based gui front end that takes at least 1G RAM to debug a couple hundred bytes of assembly code is kind of an 800 pound gorilla. But it does work and it's very pretty.

[Rob Neff]

For IDE debugging perhaps http://www.bloodshed.net/devcpp.html or https://projects.gnome.org/anjuta/ will work.  You'd need to investigate further as I can't confirm since I don't use them.  I'd be interested in hearing back any success with those tools.

[dogman]

What are you using for a debugger, command-line gdb?

[Frank Kotler]

Upon reviewing changes, I did find this in the changes for 2.08:

# Append ending token for .stabs records in the ELF output format.

This should "improve" behavior, but might cause a problem instead. I still think (and dogman confirms) that "-F dwarf" is the way to go.

Best,
Frank

[nerome]

Hello Dogman,

thanks for your inputs, this really helped. With dwarf as debugging info. format I could get insight to show the proper sources! I had a look at the obj file created by nasm 2.03.01 and objdump isn't showing any debug information either, it will still work with insight though!?

Thanks also for the debugger tips, I will definitely try some of them as soon as I find the time and let you know what I think of them.

Kind regards,
nerome

[dogman]

Hello Dogman,

thanks for your inputs, this really helped.

Wow, I can't believe I actually helped anybody! You made my day buddy! Credit where credit is due, Frank was the one to suggest using dwarf.

With dwarf as debugging info. format I could get insight to show the proper sources! I had a look at the obj file created by nasm 2.03.01 and objdump isn't showing any debug information either, it will still work with insight though!?

I didn't test it but I would expect -g -F dwarf would work from nasm 2.03 also.

Thanks also for the debugger tips, I will definitely try some of them as soon as I find the time and let you know what I think of them.

Excellent! Intel and Linux and Windows really aren't my thing and I'm usually frustrated by what I find. When I find anything that works sortof like I expect I make note of it. Solaris Studio is great but the Linux version isn't so good so I use it on Solaris. NetBeans and gdb ought to work pretty much anywhere, the only things is how much RAM it eats 

[dogman]

Upon reviewing changes, I did find this in the changes for 2.08:

# Append ending token for .stabs records in the ELF output format.

This should "improve" behavior, but might cause a problem instead. I still think (and dogman confirms) that "-F dwarf" is the way to go.

Best,
Frank

I don't know. I see the same behavior in 2.02, 2.03.01 and 2.10.04. stabs has been deprecated for awhile and I don't know where the problem is. I'm sure somebody who knows *NIX could figure it out. When I realized Intel's idb doesn't use stabs I started making a point of always specifying dwarf whenever possible and that way all the debugging stuff I have seen works better.