Bug#943579: gdb: disassembles 16-bit code (i8086) wrong

2019-10-26 Thread Thorsten Glaser 
Control: notfound 943579 6.8-3

On Sat, 26 Oct 2019, Thorsten Glaser wrote:

> Version: 8.3.1-1

> But it disassembles wrong:

Interestingly enough this is an upstream regression.

Disassembling the same code (the ELF source) with
gdb 6.3.50.20050707 on MirBSD I get this:

(gdb) set disassembly-flavor intel
(gdb) set architecture i8086
The target architecture is assumed to be i8086
(gdb) disas _start
Dump of assembler code for function _start:
0xfe00 <_start+0>:  xorecx,ecx
0xfe03 <_start+3>:  movl   ss,cx
0xfe05 <_start+5>:  movsp,0x7bfc
0xfe08 <_start+8>:  push   ecx
0xfe0a <_start+10>: data32
0xfe0b <_start+11>: popf
0xfe0c <_start+12>: movl   es,cx
0xfe0e <_start+14>: movdi,0x7c00
0xfe11 <_start+17>: push   di
[…]
(gdb) x/7i _start
0xfe00 <_start>:xorecx,ecx
0xfe03 <_start+3>:  movl   ss,cx
0xfe05 <_start+5>:  movsp,0x7bfc
0xfe08 <_start+8>:  push   ecx
0xfe0a <_start+10>: data32
0xfe0b <_start+11>: popf
0xfe0c <_start+12>: movl   es,cx

This is all as expected.

gdb 6.8-3 in Debian lenny (which I have a chroot at hand from)
behaves correctly as well. I do not know whether debugging from
a file instead of qemu is relevant as lenny’s gdb doesn’t handle
the gdbserver packets qemu sends.


bye,
//mirabilos
-- 
15:41⎜ Somebody write a testsuite for helloworld :-)

Bug#943579: gdb: disassembles 16-bit code (i8086) wrong

2019-10-26 Thread Thorsten Glaser 
Package: gdb
Version: 8.3.1-1
Severity: normal
Tags: upstream

I’m starting qemu-system-i386 with, for example, the MirBSD CD-ROM.
Then I attach gdb to qemu (started with -s -S), set a breakpoint at
the beginning of the bootsector, continue and disassemble.

(gdb) b *0x7c00
Breakpoint 1 at 0x7c00
(gdb) c
Continuing.

But it disassembles wrong:

(gdb) x/14i 0x7c00
=> 0x7c00:  xorcx,cx
   0x7c03:  movss,ecx
   0x7c05:  movesp,0x51667bfc
   0x7c0a:  popfw
   0x7c0c:  moves,ecx
   0x7c0e:  movedi,0xb1577c00
[…]
(gdb) x/14xb 0x7c00
0x7c00: 0x660x310xc90x8e0xd10xbc0xfc0x7b
0x7c08: 0x660x510x660x9d0x8e0xc1
(gdb) show architecture
The target architecture is assumed to be i8086

The correct disassembly is:
66 31 C9XOR ECX,ECX
8E D1   MOV SS,CX
BC FC 7BMOV SP,7BFCh
66 51   PUSH ECX
66 9D   POPFD
8E C1   MOV ES,CX

Putting this code snippet into “objdump -d -Mintel,i8086” gets
it almost right (except for the popfd, which nasm also gets
wrong at least when assembling):

   0:   66 31 c9xorecx,ecx
   3:   8e d1   movss,cx
   5:   bc fc 7bmovsp,0x7bfc
   8:   66 51   push   ecx
   a:   66 9d   popf
   c:   8e c1   moves,cx

ndisasm *does* get it right:

  6631C9xor ecx,ecx
0003  8ED1  mov ss,cx
0005  BCFC7Bmov sp,0x7bfc
0008  6651  push ecx
000A  669D  popfd
000C  8EC1  mov es,cx


-- System Information:
Debian Release: bullseye/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable'), 
(100, 'experimental')
Architecture: x32 (x86_64)
Foreign Architectures: i386, amd64

Kernel: Linux 5.2.0-3-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages gdb depends on:
ii  libc6 2.29-2
ii  libexpat1 2.2.9-1
ii  libgcc1   1:9.2.1-9
ii  libipt2   2.0.1-1
ii  liblzma5  5.2.4-1+b1
ii  libncursesw6  6.1+20190803-1
ii  libpython3.7  3.7.5-1
ii  libreadline8  8.0-3
ii  libstdc++69.2.1-9
ii  libtinfo6 6.1+20190803-1
ii  zlib1g1:1.2.11.dfsg-1+b1

Versions of packages gdb recommends:
ii  libc6-dbg [libc-dbg]  2.29-2

Versions of packages gdb suggests:
ii  gdb-doc8.3.1-1
pn  gdbserver  

-- no debconf information