lzma v3 fails to compile under gcc-4.3.x

[Devils-Hawk]

compiling with gcc-4.3.0 will result in the following or similar:
> error: 'memcpy' is not a member of 'std'

because gcc-4.3.0 does not include certain standard C-headers in C++ programs 
by default anymore. Attached simple stupid patch should fix that.

regards,
devh

[Uwe Hermann]

On Fri, Mar 21, 2008 at 06:33:14PM +0100, Devils-Hawk wrote:
> compiling with gcc-4.3.0 will result in the following or similar:
> > error: 'memcpy' is not a member of 'std'
>
> because gcc-4.3.0 does not include certain standard C-headers in C++ programs 
> by default anymore. Attached simple stupid patch should fix that.

Yeah, look good, but please re-post with a Signed-off-by, otherwise we
cannot commit, see
http://www.coreboot.org/Development_Guidelines#Sign-off_Procedure

Uwe.

[Devils-Hawk]

> Yeah, look good, but please re-post with a Signed-off-by, otherwise we
> cannot commit, see
> http://www.coreboot.org/Development_Guidelines#Sign-off_Procedure
>
> Uwe.

Make util/lzma compile under gcc-4.3.0

Signed-off-by: Klaus Schnass

v3 qemu and gcc-4.3.0

[Devils-Hawk]

Everything seems to be working as expected, except that the coreinfo payload 
crashes with a triple fault. Filo seems to be working just fine so i don't 
know if this is really toolchain related. I attached the log.

v3 qemu and gcc-4.3.0

[Uwe Hermann]

On Sat, Mar 22, 2008 at 12:22:23AM +0100, Devils-Hawk wrote:
> Everything seems to be working as expected, except that the coreinfo payload 
> crashes with a triple fault. Filo seems to be working just fine so i don't 
> know if this is really toolchain related. I attached the log.

This is a known issue in libpayload and/or coreinfo currently. We're not
sure yet what the problem is exactly.

Both coreinfo and libpayload do work on actual hardware and in SimNOW,
as far as I know.

Uwe.

v3 qemu and gcc-4.3.0

[Jordan Crouse]

On 22/03/08 00:22 +0100, Devils-Hawk wrote:
> Everything seems to be working as expected, except that the coreinfo payload 
> crashes with a triple fault. Filo seems to be working just fine so i don't 
> know if this is really toolchain related. I attached the log.

There is a bug somewhere that qemu is exposing, but only certain 
versions of qemu under certain situations.

You are probably crashing on the lret at the bottom of the
entry function in i386/head.S.  If you set up gdb, you should be able 
to stop execution right before the lret (if you set a breakpoint at the
ElF entrypoint, the offending instruction is only 7 or 8 instructions past
the entry).  I would like to know what is on the stack at this point (
dump the two dwords at %esp).  I'm guessing that the stack is wrong, and thats 
causing the triple fault.

Jordan

v3 qemu and gcc-4.3.0

[Devils-Hawk]

> You are probably crashing on the lret at the bottom of the
> entry function in i386/head.S.  If you set up gdb, you should be able
> to stop execution right before the lret (if you set a breakpoint at the
> ElF entrypoint, the offending instruction is only 7 or 8 instructions past
> the entry).  I would like to know what is on the stack at this point (
> dump the two dwords at %esp).  I'm guessing that the stack is wrong, and
> thats causing the triple fault.
>
> Jordan

Yes, it did crash exactly at the lret of the _entry function. After trying to 
understand some of the funkiness in head.S i came up with following patch 
which did fix the problem but i should probably still look whats going wrong 
with the original code. Its get getting quite late around here so I'll just 
post what i have and get some sleep first. ;)

Let the linker figure out the correct address and just CALL the start_main 
entry point.

Signed-off-by: Klaus Schnass

v3 qemu and gcc-4.3.0

[Jordan Crouse]

On 22/03/08 04:47 +0100, Devils-Hawk wrote:
> > You are probably crashing on the lret at the bottom of the
> > entry function in i386/head.S.  If you set up gdb, you should be able
> > to stop execution right before the lret (if you set a breakpoint at the
> > ElF entrypoint, the offending instruction is only 7 or 8 instructions past
> > the entry).  I would like to know what is on the stack at this point (
> > dump the two dwords at %esp).  I'm guessing that the stack is wrong, and
> > thats causing the triple fault.
> >
> > Jordan
>
> Yes, it did crash exactly at the lret of the _entry function. After trying to 
> understand some of the funkiness in head.S i came up with following patch 
> which did fix the problem but i should probably still look whats going wrong 
> with the original code. Its get getting quite late around here so I'll just 
> post what i have and get some sleep first. ;)
>
> Let the linker figure out the correct address and just CALL the start_main 
> entry point.
>
> Signed-off-by: Klaus Schnass

I appreciate your efforts, but since the previous code worked fine on
hardware and SimNow (and most versions of qemu, for that matter), we're
ignoring a flaw in Qemu that should be investigated.  I would hate to
cover something up that would come back to bite us later.

That said, the code below is good, with the changes below:
> Index: i386/head.S
>
> --- i386/head.S	(revision 3185)
> +++ i386/head.S	(working copy)
> @@ -50,31 +50,26 @@
>    /* No interrupts, please. */
>    cli
> /* Get the current stack pointer. */
>
> /* store current stack pointer  */
> movl %esp, %esi
>
> /* Setup new stack */
> movl _istack, %ebx

Get rid of this.
> /* lret needs %cs in the stack, so copy it over. */
> movw %cs, 4(%ebx)
> movl (%ebx), %esp

If we go with this method, then we don't need the initial stack
structure at all - replace this with

movl _stack, %esp
> /*
> * Exchange the current stack pointer for the one in the initial
> * stack (which happens to be the new stack pointer).
> */
> xchgl %esi, 16(%ebx)
> /* Save old stack pointer */
> pushl %esi
> /* Set the new stack pointer. */
> movl %esi, %esp
> /* Return into the main entry function and go. */
> lret
> /* let's rock */
> call start_main
>
> _leave:
> movl _istack, %ebx
> /* get old stack pointer */
> popl %ebx
> /* Restore the stack pointer from the storage area. */
> movl 16(%ebx), %esp
> /* restore old stack */
> movl %esp, %ebx

wrong direction - it should be
    movl %ebx, %esp
> /* Return to the original context. */
>    lret

With the changes, this should be just a ret
> Index: i386/main.c
>
> --- i386/main.c	(revision 3185)
> +++ i386/main.c	(working copy)
> @@ -36,17 +36,12 @@
> stack we store the original stack pointer from the calling application.
>
> */
>
> -static void start_main(void);
>  extern void _leave(void);
>
> static struct {
> uint32_t eip[2];
> uint32_t raddr[2];
> uint32_t esp;
>
> -} initial_stack __attribute__ ((section(".istack"))) = {
> { (uint32_t) start_main, 0 },
> { (uint32_t) _leave, 0 },
> (uint32_t) & initial_stack,
>
> +} initial_stack  __attribute__ ((section(".istack"))) = {
> (uint32_t) &initial_stack,
>
> };
>
> void *_istack = &initial_stack;

Get rid of all this.
> @@ -55,7 +50,7 @@
> This is our C entry function - set up the system
> and jump into the payload entry point.
>
> */
> -static void start_main(void)
> +void start_main(void)
>  {
>    extern int main(void);

And finally, remove the istack segment from the linker script.

Thanks,
Jordan

v3 qemu and gcc-4.3.0

[Uwe Hermann]

On Sat, Mar 22, 2008 at 04:47:36AM +0100, Devils-Hawk wrote:
> Yes, it did crash exactly at the lret of the _entry function. After trying to 
> understand some of the funkiness in head.S i came up with following patch 
> which did fix the problem but i should probably still look whats going wrong 
> with the original code. Its get getting quite late around here so I'll just 
> post what i have and get some sleep first. ;)
>
> Let the linker figure out the correct address and just CALL the start_main 
> entry point.
>
> Signed-off-by: Klaus Schnass

Thanks, committed in r3204 with some cosmetic changes. Works for me in
QEMU and on hardware.

Uwe.

v3 qemu and gcc-4.3.0

[Devils-Hawk]

> Thanks, committed in r3204 with some cosmetic changes. Works for me in
> QEMU and on hardware.

Sorry for the late response, have been busy with actual studying (scary) :) . 
The committed patch still retains the wrong directions for the last movl 
instruction. As Mr. Crouse pointed out
> /* Restore the stack pointer from the storage area. */
>   movl 16(%ebx), %esp
>   /* Restore old stack. */
>   movl %esp, %ebx

should really be
>      movl %ebx, %esp

I have a patch that adresses the rest of the raised issues but it mysteriously 
dies somewhere in vga init. Haven't yet had the time to take a closer look.
Attached, maybe somebody knows whats going wrong. ;) No sign-off because the 
patch is not working. ;)

best regards, devh

PS: hopefully ddd gets a new maintainer, this tool rocks! ;)

v3 qemu and gcc-4.3.0

[Devils-Hawk]

On Wednesday 02 April 2008 21:16:29 Devils-Hawk wrote:
> closer look. Attached, maybe somebody knows whats going wrong. ;) No
> sign-off because the patch is not working. ;)

Whoops! One > too many! New patch attached. Hmm ... and i found out whats 
going wrong with qemu. Sometimes a piece of art says more than words. The 
only question is it even supposed to work. I had to work with this really old 
assembly editor once and i think that it did not allow that kind of mov 
instructions, only register - register transfer to %esp.

regards devh

PS: patch still not working

v3 qemu and gcc-4.3.0

[Uwe Hermann]

On Wed, Apr 02, 2008 at 09:44:20PM +0200, Devils-Hawk wrote:
> Whoops! One > too many! New patch attached. Hmm ... and i found out whats 
> going wrong with qemu. Sometimes a piece of art says more than words. The 
> only question is it even supposed to work. I had to work with this really old 
> assembly editor once and i think that it did not allow that kind of mov 
> instructions, only register - register transfer to %esp.
>
> regards devh
>
> PS: patch still not working

Please post _all_ patches with Signed-off-by, whether working or not,
someone else might fix a non-working patch and commit it.

I'll let Jordan review your changes, but one quick question: does the
_current_ svn work for you? It works fine here (QEMU 0.9.1), or well,
at least good enough that it doesn't triple-fault anymore.

Uwe.

[Uwe Hermann]

On Fri, Mar 21, 2008 at 10:46:27PM +0100, Devils-Hawk wrote:
> Make util/lzma compile under gcc-4.3.0
>
> Signed-off-by: Klaus Schnass

Confirmed, the patch fixes the build with gcc/g++ 4.3, committed in r646.

Can you check if v2 has the same problem?

Thanks, Uwe.