[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: