Re: DDD 3.3.11 for beginners in assembly programming

[R. Bernstein]

Zarko reports: 

>  My colleagues and I are teaching an 80386 assembly course at the
>  Faculty of technical sciences, Novi Sad, Serbia and Montenegro....
>  Our choice for a debugger was (and still is) DDD. During the last
>  year, we encountered the most common problems that our students had
>  when using DDD, and this is an attempt to make DDD more user-friendly
>  for beginners in assembly programming. 

Obviously, making DDD more user-friendly is something that is
disirable; and can only be determined by, well, users. At least this
"developer" doesn't often get such feedback. So thanks for reporting
back the students' experiences.

Changes were made in original
>  DDD 3.3.11 sources because we wanted to give the students an easy to
>  install version, without any need for adjustments after installation.

Am I missing something here? Why not use 3.3.12 sources? Is there
something in 3.3.12 that makes 3.3.11 more desirable?

>  List of changes:

>  1. Clicking on any register in Registers window will put "/x $reg_name"
>     in the argument field, which is good if you want to display it's value
>     as a hex number. But, if you want to change a register value, this way
>     you first need to delete the "/x" part, and then to click on Set. Because
>   the Registers window already shows all register's values in hex and dec,
>   the default behavior when clicking on register in Registers window
>   was changed to put only a "$reg_name" in argument field.

This change sounds okay to me. I'd like to hear if any others have any
comments.

>2. DDD can directly show 32-bit registers, but not 8 or 16-bit, nor the values 
>of
>   individual flags (as far as I know). ...

Again this sounds like a good thing. But see below.

>   Also, to allow easier access to these registers and flags, some default data
   buttons were added 

This too sounds okay if they can be added in a way that doesn't get in
the way when they are not useful. In my opinion there already are a
too many of buttons that aren't used all that much. For example
"stepi" (step instruction) isn't useful in any of the interpreted
languages (Bash, Make, Perl, Python). I even wonder how often it's
used for C or C++. 

One can add custom buttons in the Ddd resource. For example:

  ! Buttons.
  Ddd*consoleButtons: \
  debug\n\
  return
  Ddd*sourceButtons: 
  Ddd*dataButtons: 


> 3. When you have an assembly line like this:
>   movw array(,%ecx,2), %ax
>   there is no easy way to show memory addressed by "array(,%ecx,2)",
.   which is very useful for debugging. This was solved via Data/Memory
>   dialog, which was changed to handle these expressions.

Also probably a good thing if it can be done in a general way.

> 4. Some default settings were changed, because students were confused by them 
(like
>    Suppress X warnings, keyboard focus : click to type, and so on). Also, 
> some 
default
>    source buttons were added (for displaying strings and 8-bit data)

Again, I'm personally okay with this based on your observations from
students.  Perhaps others reading the mailing will express their
views.

> I am aware that most of these changes may be called "quick and dirty"
> programming, and that they may corrupt DDD behavior with non-386
> assembly programs, but I don't know enough about DDD internals to make
> them cleaner. 

I looked at the changes and alas they are perhaps a little bit custom
for your environment.

> I didn't found much documentation about DDD (especially
> about writing themes and using data displays) and currently I don't
> have the time to analyze it in details. If someone has any suggestions
> about cleaning up this code, or finds it useful, please let me know.

Some comments on what I found. 

1. The styles regs.vsl, flags.vsl which for dealing with those Intel
   x86 registers and Intel register flags I think should be renamed
   something more Intel x86 suggestive, like i386regs.vsl and
   i386flags.vsl. 

2. Those two styles are loaded by default. A first cut at doing better
   would be to test to see if the gdb debugger is used. This is done
   by using by comparing gdb->type() to GDB, e.g. gdb->type() ==
   GDB. Even better would be to issue the gdb command "show
   architecture" and look for i386.

   Another approach that I think would work just as well would be to
   install the profile as part of your Ddd X resources file.  It looks
   like the resources  
   Ddd*vslLibrary: i386.vsl

   where i386.vsl is just:
     #include "i386regs.vsl"
     #include "i386flags.vsl"

   In fact, one might want to have a i586.vsl or i686.vsl which uses
   some of the i386 definitions. So I suggest that when this goes into
   ddd (and I think it should), this may be a better organization.

3. I notice you comment in something that looks like transliterated
   Russian (or Ukranian?) into the Roman alphabet. Personally, it
   doesn't bother me in the slightest; if it's okay with others too,
   we'll keep the comments.

Lastly, I'm about to put in another test release (I'll probably
announce that on the list soon). Because the changes need to be gone
over, may be controversial (although I don't think so), best to leave
this for a separate release.