Re: Problem trying to get DDD to debug a simple assembly language program

[shaunak saha]

Tim,

Nicely explained.

>In my experience with ddd and various inferior debuggers, a lot of the
>"hourglass" issues happen when ddd doesn't understand the results it
>received from the inferior.  It's looking for a response to a command and
>it got something it doesn't know how to handle.

>ddd logs this interaction with the inferior debugger in ~/.ddd/log.  I
>recommend you exit ddd, remove the current log file, and then restart
>with the same parameters as before.  Then investigate the log and see
>what's at or near the end.

Rich, if you can do this and send us the "log" file it would be greatly helpful.

>ddd hasn't seen any maintenance in years.  It's possible that there's
>been changes to how the inferior debugger outputs certain messages, and
>that's causing ddd to not handle it correctly.

I totally agree that its time to make a new release and I am working on it..

On Thu, Apr 4, 2013 at 3:07 PM, Tim Mooney <address@hidden> wrote:

In regard to: Problem trying to get DDD to debug a simple assembly language...:

I have a Zareason 64 bit laptop running Ubuntu Linux 12.10 64 bit. Have been reading an "Assembly language step by step" book and have been attempting to use ddd
to  debug. Obtained ddd from Ubuntu software center download.
Have compiled: nasm -f elf64 -g -F dwarf junk.asm
Linked: ld -o junk junk.o
The program from terminal successfully prints "Eat at Joe's!" as it should.

However, when I try to load it into ddd  the program hangs and I get a
continuous hourglass. The code "displays", but I can't set breakpoints
or do anything else.

Remember that ddd is essentially a graphical front end to an underlying
debugger that's actually doing most of the work.  In ddd parlance, the other
debugger is frequently called the "inferior" debugger, but without
the negative connotations.

By default, ddd is going to use the GNU debugger, gdb, as the inferior.
When you start up ddd, it will run gdb on your behalf, sending it commands
based on actions you perform in the ddd GUI (like setting breakpoints,
stepping through code, etc.).  ddd also must read the inferior's response
and interpret it for display on the GUI.

In my experience with ddd and various inferior debuggers, a lot of the
"hourglass" issues happen when ddd doesn't understand the results it
received from the inferior.  It's looking for a response to a command and
it got something it doesn't know how to handle.

ddd logs this interaction with the inferior debugger in ~/.ddd/log.  I
recommend you exit ddd, remove the current log file, and then restart
with the same parameters as before.  Then investigate the log and see
what's at or near the end.

 The only way I can get it to load is from the
terminal, i.e ____$ddd junk.

When I do the above. I note that the terminal lists several Warnings, e.g Warning: Cannot convert string "-*helvetica-medium-r .....and Warning: could not load font....."
I believe leaving the cursor hung up also.

ddd is a Motif-based program, so it uses the older style names for fonts.
These are all configurable, though.  There's a resource file that's
installed with ddd that establish many of the defaults, and you can
override those either within the application or by setting X-style
resource declarations.

I recommend you try starting ddd with no options, and then go into

        Edit->Preferences->Fonts

and try browsing to find suitable fonts for your workstation.

I've tried web sites and reading the ddd manual, but am at a loss. I
suspect I'm doing something silly, but would appreciate any feedback.
Could it be ddd doesn't handle 64 bit code? Note the same thing happens,
even if I use the 32-bit book version that was already compiled when
unzipped?!

I don't think it's anything you're doing wrong.

ddd hasn't seen any maintenance in years.  It's possible that there's
been changes to how the inferior debugger outputs certain messages, and
that's causing ddd to not handle it correctly.

Keep in mind that debugging assembly is probably much less common than
debugging C or C++ with ddd, so that too adds to the likelihood that
you'll run into issues that few other people have seen before.

Tim
--
Tim Mooney                                             address@hidden
Enterprise Computing & Infrastructure                  701-231-1076 (Voice)
Room 242-J6, IACC Building                             701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164