Mail Archives: djgpp/1997/10/09/20:06:09
At 04:45 10/9/1997 GMT, M. Schulter wrote:
>Hi, there.
>
>This message is to ask a question about the way that fsdb represents
>the `cltd' instruction in an AT&T assembler program for GAS as `cdw'
>instead of `cdq' in its Intel (or Intel-like?) disassembly display.
>
>According to
>
>info as machine i386 i386-opcodes
>
>the AT&T `cltd' instruction is equivalent to Intel `cdq': a 32-bit
>integer gets sign-extended to 64 bits. So far, I've used this before a
>64-bit division, as in the attached brief program.
>
>For some reason, however, fsdb shows the instruction as `cwd' -- which
>sign-extends a word to a dword (in other words, a word to a long or
>int in GAS terminology).
>
>This happens for me with DJGPP 2.01, using a version of fsdb
>(identified on the System Info screen as v. 1.00) with a date for the
>executable of 31 October 1996.
>
>Since I'm just learning assembly, I wonder if this is indeed
>unexpected behavior in fsdb, a great debugger which I have found
>indispensable both in routine learning and bug-detecting.
>
>By the way, my apologies for any infelicities or nonobvious bugs in
>the program which follows; when I compile it, fsdb runs it fine, but
>displays my `cltd' as `cdw' rather than `cdq'.
Yeah, this is fsdb's fault. The problem is that `cdw' and `cdq' have the
same opcode, and are distinguished by either their presence in a 16- or
32-bit segment, or by a prefix byte. (An ugly kludge on Intel's part, IMHO.)
This is, AFAIK, the only case in which this actually changes the name of the
opcode (in Intel syntax). Usually it's a matter of using %ax vs. %eax, 16-
vs. 32-bit registers. It seems fsdb is not smart enough to be able to change
the opcode name depending on the operand size. I guess you can either live
with it, or add the feature to fsdb.
Nate Eldredge
eldredge AT ap DOT net
- Raw text -