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

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 <[email protected]> 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                                             [email protected]
> Enterprise Computing & Infrastructure                  701-231-1076(Voice)
> Room 242-J6, IACC Building                             701-231-8541 (Fax)
> North Dakota State University, Fargo, ND 58105-5164
>
>