bugThe GNU Hurd - Bugs: bug #17338, GNU Mach vs. GCC 4.1

 
 

bug #17338: GNU Mach vs. GCC 4.1

Submitter:  Thomas Schwinge <tschwinge>
Submitted:  Sat 05 Aug 2006 11:09:58 PM UTC
   
 
Category:  GNU Mach Severity:  4 - Important
Priority:  7 - High Item Group:  Standard Compliance
Status:  Fixed Privacy:  Public
Assigned to:  sthibaul Originator Name: 
Open/Closed:  Closed Reproducibility:  Every Time
Size (loc):  None Planned Release:  GNU Mach 1.4
Effort:  0.00
Wiki-like text discussion box: 


* Mandatory Fields

Add a New Comment Rich Markup
   

Mon 18 Sep 2006 07:37:13 PM UTC, comment #5: 

Ok.

Please check in file #10478 (patch-gnumach-seg-1) and then mark this bug as `fixed' and `closed'.

I'd suggest the following for the ChangeLog entry:

#v+
[current date]  Samuel Thibault  <samuel.thibault@ens-lyon.org>

        * i386/i386/seg.h (struct pseudo_descriptor): Pack structure and move the
        padding field to the end.
        (lgdt): Pass the whole structure to the lgdt assembly command.
        (lidt): Likewise.
#v-

Thomas Schwinge <tschwinge>
Group administrator
Mon 18 Sep 2006 06:21:38 PM UTC, comment #4: 


> +       short pad;
> Why do we need that padding field at all?


Because there are arrays of struct pseudo_descriptor, which the hardware require to have this big items.

Samuel Thibault <sthibaul>
Group administrator
Mon 18 Sep 2006 06:16:25 PM UTC, comment #3: 

Quoting from file #10478 (patch-gnumach-seg-1):

#v+
[...]
--- i386/i386/seg.h     5 Apr 2001 06:39:20 -0000       1.2
+++ i386/i386/seg.h     7 Aug 2006 03:59:04 -0000
@@ -121,20 +121,20 @@ struct real_gate {
 /* Format of a "pseudo-descriptor", used for loading the IDT and GDT.  */
 struct pseudo_descriptor
 {
-       short pad;
        unsigned short limit;
        unsigned long linear_base;
-};
+       short pad;
+} _attribute_((packed));
[...]
#v-

Why do we need that padding field at all?

Thomas Schwinge <tschwinge>
Group administrator
Sat 26 Aug 2006 09:55:15 AM UTC, comment #2: 

Hi,

Still no decision on this. I'm just wondering: will gnumach ever be compiled by something else than gcc? If not, then the "nice solution" (patch-gnumach-seg-1) can be safely applied (since gcc supports the "packed" attribute since a long time).

Regards,
Samuel

Samuel Thibault <sthibaul>
Group administrator
Mon 07 Aug 2006 04:27:10 AM UTC, comment #1: 

GCC gets smarter and smarter...  When seeing this:

struct pseudo_descriptor
{
short pad;
unsigned short limit;
unsigned long linear_base;
}
MACH_INLINE void lgdt(struct pseudo_descriptor *pdesc)
{
        __asm volatile("lgdt %0" : : "m" (pdesc->limit));
}
gdt_init() {
...
{
                struct pseudo_descriptor pdesc;

                pdesc.limit = sizeof(gdt)-1;
                pdesc.linear_base = kvtolin(&gdt);
                lgdt(&pdesc);
        }
}

, it understands that filling the linear_base field is not needed, since we only give the limit field to the asm statement... The result it this:

gcc 4.0:
<gdt_init+102>:      movw   $0x57,0xfffffffa(%ebp)
<gdt_init+108>:      movl   $0xc0000000,0xfffffffc(%ebp)
<gdt_init+115>:      lgdtl  0xfffffffa(%ebp)

gcc 4.1:
<gdt_init+102>:      movw   $0x57,0xfffffffa(%ebp)
<gdt_init+108>:      lgdtl  0xfffffffa(%ebp)

it doesn't fill the linear_base field!

There are two possible fixes, that I'll attach:

- reorder the structure, pack it, and give it as a whole to the asm statement.
- clobber memory in the asm statement.

My preference goes to the first, since it explains to gcc what we exactly want. That supposes the support of the "packed" attribute, however.

Samuel Thibault <sthibaul>
Group administrator
Sat 05 Aug 2006 11:09:58 PM UTC, original submission:  

GNU Mach, built with GCC 4.1, immediatelly makes the system reboot after being executed by GRUB.

This was confirmed a) with the standard Debian tool chain and Debian gnumach package and b) with a cross compiler tool chain, gnumach-1-branch and compiling in only a minimal set of device drivers.

Thomas Schwinge <tschwinge>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #10479:  patch-gnumach-seg-2 added by sthibaul (1013B - application/octet-stream - more dirty solution)
file #10478:  patch-gnumach-seg-1 added by sthibaul (1KiB - application/octet-stream - nice solution)

 

Depends on the following items: None found

Items that depend on this one

Digest:
   task dependencies.

 

CC list is empty

 

There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

Only logged-in users can vote.

 

Follow 8 latest changes.

Date Changed by Updated Field Previous Value => Replaced by
2006-11-16 tschwinge Dependencies- task #6111 is dependent
2006-09-19 sthibaul StatusIn Progress Fixed
    Open/ClosedOpen Closed
2006-09-18 tschwinge Assigned toNone sthibaul
2006-09-18 tschwinge StatusConfirmed In Progress
    Carbon-Copy- Added sthibaul
2006-08-07 sthibaul Attached File- Added patch-gnumach-seg-2, #10479
2006-08-07 sthibaul Attached File- Added patch-gnumach-seg-1, #10478

Back to the top

Powered by Savane 3.13-d3ae.
Corresponding source code