Bug#122511: marked as done (gcc: illegal instructions and bad jump offsets when VMA != LMA)
Your message dated Sat, 28 Dec 2002 15:03:40 +0100
with message-id <15885.44860.521717.90770@gargle.gargle.HOWL>
and subject line closing report due to missing feedback
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--------------------------------------
Received: (at submit) by bugs.debian.org; 5 Dec 2001 11:14:08 +0000
>From wli@holomorphy.com Wed Dec 05 05:14:08 2001
Return-path: <wli@holomorphy.com>
Received: from holomorphy.com (holomorphy) [216.36.33.161] (mail)
by master.debian.org with esmtp (Exim 3.12 1 (Debian))
id 16Ba08-00076e-00; Wed, 05 Dec 2001 05:14:08 -0600
Received: from wli by holomorphy with local (Exim 3.31 #1 (Debian))
id 16Ba03-0003K4-00; Wed, 05 Dec 2001 03:14:03 -0800
From: wli@holomorphy.com
Subject: gcc: illegal instructions and bad jump offsets when VMA != LMA
To: submit@bugs.debian.org
X-Mailer: bug 3.3.9
Message-Id: <E16Ba03-0003K4-00@holomorphy>
Date: Wed, 05 Dec 2001 03:14:03 -0800
Delivered-To: submit@bugs.debian.org
Package: gcc
Version: 2:2.95.4-4
Severity: normal
This one's not easy to diagnose on my end. I'll cut and paste objdump's
with --source to give an idea of the flavor. Similar bugs happen on all
combinations of binutils and gcc I've tried, which are gcc2.95.4 packages
of several versions and gcc3.0 packages of several versions, and a couple
of versions of binutils I forgot plus the latest (2.11.90.0.31).
I've got the source for the thing where this happens up on
klecker:/org/home/wli/x86init.tar.gz
I'll arrange the sources so that #defining MISCOMPILE causes this
code to be generated.
First, the miscompiled code:
for(k = 0U; k < 4096U; ++k) {
111076: c7 45 f8 00 00 00 00 movl $0x0,0xfffffff8(%ebp)
11107d: 00 00 add %al,(%eax)
11107f: 00 81 7d f8 ff 0f add %al,0xffff87d(%ecx)
111085: 00 00 add %al,(%eax)
111087: 76 07 jbe 111090 <initialize_kernel_virtual
_addressing+0x38>
111089: eb 55 jmp 1110e0 <initialize_kernel_virtual
_addressing+0x88>
11108b: 00 00 add %al,(%eax)
11108d: 00 00 add %al,(%eax)
11108f: 00 8b 45 f8 89 c2 add %cl,0xc289f845(%ebx)
low_page_table_entries[k]
111095: 8d 04 95 00 00 00 00 lea 0x0(,%edx,4),%eax
11109c: ba 00 30 11 00 mov $0x113000,%edx
1110a1: 8b 4d f8 mov 0xfffffff8(%ebp),%ecx
1110a4: 89 cb mov %ecx,%ebx
1110a6: 89 d9 mov %ebx,%ecx
1110a8: c1 e1 0c shl $0xc,%ecx
1110ab: 89 cb mov %ecx,%ebx
1110ad: 83 cb 07 or $0x7,%ebx
1110b0: 89 1c 10 mov %ebx,(%eax,%edx,1)
= (4096*k)
| PAGE_PRESENT_FIELD
| PAGE_SUPERVISOR_FIELD
| PAGE_WRITABLE_FIELD;
high_page_table_entries[k]
1110b3: 8b 45 f8 mov 0xfffffff8(%ebp),%eax
1110b6: 89 c2 mov %eax,%edx
1110b8: 8d 04 95 00 00 00 00 lea 0x0(,%edx,4),%eax
1110bf: ba 00 70 11 00 mov $0x117000,%edx
1110c4: 8b 4d f8 mov 0xfffffff8(%ebp),%ecx
1110c7: 89 cb mov %ecx,%ebx
1110c9: 89 d9 mov %ebx,%ecx
1110cb: c1 e1 0c shl $0xc,%ecx
1110ce: 89 cb mov %ecx,%ebx
1110d0: 83 cb 07 or $0x7,%ebx
1110d3: 89 1c 10 mov %ebx,(%eax,%edx,1)
1110d6: ff 45 f8 incl 0xfffffff8(%ebp)
1110d9: eb a5 jmp 111080 <initialize_kernel_virtual
_addressing+0x28>
1110db: 00 00 add %al,(%eax)
1110dd: 00 00 add %al,(%eax)
1110df: 00 c7 add %al,%bh
= (4096*k)
| PAGE_PRESENT_FIELD
| PAGE_SUPERVISOR_FIELD
| PAGE_WRITABLE_FIELD;
}
#endif
Note that 0x111080 is not on an instruction boundary.
An equivalent loop coded with gotos (the while is similarly miscompiled):
#if 1
k = 0U;
111076: c7 45 f8 00 00 00 00 movl $0x0,0xfffffff8(%ebp)
level_2_page_table_loop: {
low_page_table_entries[k]
11107d: 8b 45 f8 mov 0xfffffff8(%ebp),%eax
111080: 89 c2 mov %eax,%edx
111082: 8d 04 95 00 00 00 00 lea 0x0(,%edx,4),%eax
111089: ba 00 30 11 00 mov $0x113000,%edx
11108e: 8b 4d f8 mov 0xfffffff8(%ebp),%ecx
111091: 89 cb mov %ecx,%ebx
111093: 89 d9 mov %ebx,%ecx
111095: c1 e1 0c shl $0xc,%ecx
111098: 89 cb mov %ecx,%ebx
11109a: 83 cb 07 or $0x7,%ebx
11109d: 89 1c 10 mov %ebx,(%eax,%edx,1)
= (4096*k)
| PAGE_PRESENT_FIELD
| PAGE_SUPERVISOR_FIELD
| PAGE_WRITABLE_FIELD;
high_page_table_entries[k]
1110a0: 8b 45 f8 mov 0xfffffff8(%ebp),%eax
1110a3: 89 c2 mov %eax,%edx
1110a5: 8d 04 95 00 00 00 00 lea 0x0(,%edx,4),%eax
1110ac: ba 00 70 11 00 mov $0x117000,%edx
1110b1: 8b 4d f8 mov 0xfffffff8(%ebp),%ecx
1110b4: 89 cb mov %ecx,%ebx
1110b6: 89 d9 mov %ebx,%ecx
1110b8: c1 e1 0c shl $0xc,%ecx
1110bb: 89 cb mov %ecx,%ebx
1110bd: 83 cb 07 or $0x7,%ebx
1110c0: 89 1c 10 mov %ebx,(%eax,%edx,1)
= (4096*k)
| PAGE_PRESENT_FIELD
| PAGE_SUPERVISOR_FIELD
| PAGE_WRITABLE_FIELD;
++k;
1110c3: ff 45 f8 incl 0xfffffff8(%ebp)
if(k < 4096U)
1110c6: 81 7d f8 ff 0f 00 00 cmpl $0xfff,0xfffffff8(%ebp)
1110cd: 77 02 ja 1110d1 <initialize_kernel_virtual
_addressing+0x79>
goto level_2_page_table_loop;
1110cf: eb ac jmp 11107d <initialize_kernel_virtual
_addressing+0x25>
}
In this case the code runs, boots, and all the jump offsets line up.
I've had a much tougher time reproducing the illegal instructions,
but they seemed to crop up often without -m386 -O0
These are fairly simple for loops so I suspect there is some interaction
between the compiler and linker which is not being done properly in order
to handle the case where LMA != VMA, but I don't have any specifics.
I haven't looked very hard at the generated assembly, either, which could
perhaps tell people whether it's gcc's or binutils' fault alone.
make x86init will make the good executable.
env CFLAGS=-DMISCOMPILE make x86init will make the miscompiled one.
Well, after changing the #ifdefs the jump offsets moved around, but
they're still off. There's this:
111081: 81 7d f8 ff 0f 00 00 cmpl $0xfff,0xfffffff8(%ebp)
111088: 76 06 jbe 111090 <initialize_kernel_virtual_addressing+0x34>
11108a: eb 54 jmp 1110e0 <initialize_kernel_virtual_addressing+0x84>
11108c: 00 00 add %al,(%eax)
where it's trying to land somewhere around here:
1110dd: 00 00 add %al,(%eax)
1110df: 00 c7 add %al,%bh
1110e1: 45 inc %ebp
1110e2: f8 clc
And this is supposed to be a call to a procedure (no inline asm)
called boot_write_cr3()
111165: 20 11 and %dl,(%ecx)
111167: 00 e8 add %ch,%al
111169: fa cli
11116a: 9e sahf
11116b: 00 00 add %al,(%eax)
11116d: 83 c4 10 add $0x10,%esp
... this is code generated by gcc, no inline asm or other dirty tricks.
Cheers,
Bill
-- System Information
Debian Release: testing/unstable
Kernel Version: Linux holomorphy 2.4.17-pre1-vanilla #1 Sat Dec 1 14:28:18 PST 2001 i686 unknown
Versions of the packages gcc depends on:
ii cpp 2.95.4-4 The GNU C preprocessor.
ii cpp-2.95 2.95.4-0.01070 The GNU C preprocessor.
ii gcc-2.95 2.95.4-0.01100 The GNU C compiler.
---------------------------------------
Received: (at 122511-done) by bugs.debian.org; 28 Dec 2002 14:08:02 +0000
>From doko@cs.tu-berlin.de Sat Dec 28 08:08:02 2002
Return-path: <doko@cs.tu-berlin.de>
Received: from mail.cs.tu-berlin.de [130.149.17.13] (root)
by master.debian.org with esmtp (Exim 3.12 1 (Debian))
id 18SHdA-00076z-00; Sat, 28 Dec 2002 08:08:00 -0600
Received: from bolero.cs.tu-berlin.de (daemon@bolero.cs.tu-berlin.de [130.149.19.1])
by mail.cs.tu-berlin.de (8.9.3/8.9.3) with ESMTP id PAA02350
for <122511-done@bugs.debian.org>; Sat, 28 Dec 2002 15:03:40 +0100 (MET)
Received: (from doko@localhost)
by bolero.cs.tu-berlin.de (8.11.6+Sun/8.9.3) id gBSE3eU21226;
Sat, 28 Dec 2002 15:03:40 +0100 (MET)
From: Matthias Klose <doko@cs.tu-berlin.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15885.44860.521717.90770@gargle.gargle.HOWL>
Date: Sat, 28 Dec 2002 15:03:40 +0100
To: 122511-done@bugs.debian.org
Subject: closing report due to missing feedback
X-Mailer: VM 7.03 under 21.4 (patch 6) "Common Lisp" XEmacs Lucid
Delivered-To: 122511-done@bugs.debian.org
X-Spam-Status: No, hits=0.6 required=5.0
tests=SPAM_PHRASE_00_01
version=2.41
X-Spam-Level:
asked for feedback on Sun, 14 Jul 2002 17:56:49 +0200.
no response. therefore closing the report ...
feel free to reopen the report sending updated information using
recent gcc (3.2.[12]) and binutils (2.13.90.0.16).
Reply to: