URL:
<>
Summary: GNU Mach vs. GCC 4.1
Project: The GNU Hurd
Submitted by: tschwinge
Submitted on: Sunday 08/06/06 at 01:09
Category: GNU Mach
Severity: 4 - Important
Priority: 7 - High
Item Group: Standard Compliance
Status: Confirmed
Privacy: Public
Assigned to: None
Name:
Email:
/Closed:
Reproducibility: Every Time
Size (loc): None
Planned Release: GNU Mach 1.4
Effort: 0.00
Details:
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.
Reply to this item at:
<>
Message sent via/by Savannah
http://savannah.gnu.org/
Bug-hurd mailing list
Bug-hurd (AT) gnu (DOT) org

Follow-up Comment #1, bug #17338 (project hurd):

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.

Reply to this item at:

<>

Message via/par Savannah
http://savannah.gnu.org/

Bug-hurd mailing list
Bug-hurd (AT) gnu (DOT) org

Additional Item Attachment, bug #17338 (project hurd):

File name: patch-gnumach-seg-1 Size:1 KB
nice solution
<>

Reply to this item at:

<>

Message via/par Savannah
http://savannah.gnu.org/

Bug-hurd mailing list
Bug-hurd (AT) gnu (DOT) org

Additional Item Attachment, bug #17338 (project hurd):

File name: patch-gnumach-seg-2 Size:0 KB
more dirty solution
<>

Reply to this item at:

<>

Message via/par Savannah
http://savannah.gnu.org/

Bug-hurd mailing list
Bug-hurd (AT) gnu (DOT) org

BTW, there are other places that might need such fixes: fnsave, frstor
& alike _do_ manipulate memory, and hence should clobber it. Lock
and bit set/clear macros should too. And there are sometimes some
spurious volatiles: the first get_eflags() definition for instance. And
just using things like unsigned long register sp asm("esp"); is just
sufficient when it works.

BTW again, I noticed that pio macros' header is not always included,
so that some objects use the in[bwl]/out[bwl] functions instead of the
macros that get much better inlined.

Samuel

Bug-hurd mailing list
Bug-hurd (AT) gnu (DOT) org

Hello!

Mon, Aug 07, 2006 at 06:31:33AM +0200, Samuel Thibault wrote:
BTW, there are other places that might need such fixes: []

Samuel, thanks for doing that!

Feel free to ``go wild'' with all that code while I'll be away from this
week's Wednesday until early in September. (Invited to France -- 86000
Poitiers; someone in that area? -- to join an orchestra and give six
concerts in Canada -- M, Q, Trois-R area.) :-)

I'll deal with these issues as soon as I'm back.

Everyone, please use this very mailing list and not the #hurd irc channel
for reporting stuff. :-)

Regards,
Thomas

Bug-hurd mailing list
Bug-hurd (AT) gnu (DOT) org

PGP SIGNATURE
Version: GnuPG v1.2.5 (GNU/Linux)

gyueYTRDI4vc8zu9y+3qRmQ=
=tJ8e
PGP SIGNATURE

Thomas Schwinge, le Mon 07 Aug 2006 12:35:58 +0200, a :
Mon, Aug 07, 2006 at 06:31:33AM +0200, Samuel Thibault wrote:
BTW, there are other places that might need such fixes: []

Samuel, thanks for doing that!

Feel free to ``go wild'' with all that code while I'll be away from this
week's Wednesday until early in September.

Tomorrow, I'll take my bike for a 2-weeks tour in Belgium :)

Samuel

Bug-hurd mailing list
Bug-hurd (AT) gnu (DOT) org

Follow-up Comment #2, bug #17338 (project hurd):

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

Reply to this item at:

<>

Message sent via/by Savannah
http://savannah.gnu.org/

Bug-hurd mailing list
Bug-hurd (AT) gnu (DOT) org

Update of bug #17338 (project hurd):

Status: Confirmed =In Progress

Follow-up 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?

Reply to this item at:

<>

Message sent via/by Savannah
http://savannah.gnu.org/

Bug-hurd mailing list
Bug-hurd (AT) gnu (DOT) org

Follow-up Comment #4, bug #17338 (project hurd):

+ 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.

Reply to this item at:

<>

Message via/par Savannah
http://savannah.gnu.org/

Bug-hurd mailing list
Bug-hurd (AT) gnu (DOT) org

Update of bug #17338 (project hurd):

Assigned to: None =sthibaul

Follow-up Comment #5:

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 (AT) ens-lyon (DOT) 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-

Reply to this item at:

<>

Message sent via/by Savannah
http://savannah.gnu.org/

Bug-hurd mailing list
Bug-hurd (AT) gnu (DOT) org

Update of bug #17338 (project hurd):
Status: In Progress =Fixed
/Closed: =Closed
Reply to this item at:
<>
Message via/par Savannah
http://savannah.gnu.org/
Bug-hurd mailing list
Bug-hurd (AT) gnu (DOT) org

Hello!

Mon, Aug 07, 2006 at 06:27:11AM +0200, Samuel Thibault wrote:
GCC gets smarter and smarter When seeing this:

[]

As there seems to be general interest: can you explain what techniques
and tools you used to locate that problem?

elfutils's elfcmp? objdump with shell script hackery? Just reading the
source code? Pure chance?

Regards,
Thomas

Bug-hurd mailing list
Bug-hurd (AT) gnu (DOT) org

PGP SIGNATURE
Version: GnuPG v1.2.5 (GNU/Linux)

CV/WEB/FaVKUeSio=
=7pif
PGP SIGNATURE

Hi,

Thomas Schwinge, le Tue 19 Sep 2006 12:47:35 +0200, a :
Mon, Aug 07, 2006 at 06:27:11AM +0200, Samuel Thibault wrote:
GCC gets smarter and smarter When seeing this:

[]

As there seems to be general interest: can you explain what techniques
and tools you used to locate that problem?

elfutils's elfcmp? objdump with shell script hackery? Just reading the
source code? Pure chance?

Just like the de4x5 probe hangup: inserting things like
* (unsigned long*) 0xb8000 = 'A';
and
* (unsigned long*) 0xb8000 = 'B';
etc. spread around the kernel (+ some while(1); if the symptom is a
systematic machine reboot) and by dichotomy I could find that the
problem was gdt_init. I had it print the values, found them correct, so
as last resort, run gdb kernel, disassemble gdt_init, and then found out
the optimization.

Samuel

Bug-hurd mailing list
Bug-hurd (AT) gnu (DOT) org