[edk2] OVMF x64 - CR has Bad Signature

[Cristiano Fernandes]

Hi all,

IŽm trying to build a simple tcp echo server application using StdLib.

Building IA32 (GCC Linux) + Running OVMF IA32:
Works fine.

Building IA32 or X64 (VS2008 Windows) + Running OVMF IA32 or X64:
Works fine.

Building X64 (GCC Linux) + Running OVMF X64:
I get an ASSERT error (ASSERT
/home/user/edk2/MdeModulePkg/Universal/Network/Tcp4Dxe/Tcp4Main.c(198):
CR has Bad Signature) which ends on CpuDeadLoop().

The first think that came to my mind is the difference between LP64 (Linux)
and LLP64 (Windows), but I donŽt know if this could affect "CR" signature
check or efi binary at all.

IŽm using GCC44 on a Fedora 16 X64.

Thanks in advance,

[Andrew Fish]

Post by Cristiano Fernandes
Hi all,
IŽm trying to build a simple tcp echo server application using StdLib.
Works fine.
Works fine.
I get an ASSERT error (ASSERT /home/user/edk2/MdeModulePkg/Universal/Network/Tcp4Dxe/Tcp4Main.c(198): CR has Bad Signature) which ends on CpuDeadLoop().

An error like this usually means either the passed in pointer was not valid, or data corruption has happened. You could add some DEBUG prints of the structure to see if is wrong or corrupt?

This brings up something I've been thinking about. It would be useful to have a version of the DEBUG print that does a hex dump. Maybe DEBUG_HEX_DUMP (address, size)
00000000 23 0a 23 20 43 6f 70 79 72 69 67 68 74 20 28 63 |#.# Copyright (c|
00000010 29 20 32 30 30 36 20 2d 20 32 30 31 30 2c 20 49 |) 2006 - 2010, I|
00000020 6e 74 65 6c 20 43 6f 72 70 6f 72 61 74 69 6f 6e |ntel Corporation|
00000030 2e 20 41 6c 6c 20 72 69 67 68 74 73 20 72 65 73 |. All rights res|
00000040 65 72 76 65 64 2e 3c 42 52 3e 0a 23 20 54 68 69 |erved.<BR>.# Thi|

This would be helpful in debugging memory corruption issues. What do folks think?

Post by Cristiano Fernandes
The first think that came to my mind is the difference between LP64 (Linux) and LLP64 (Windows), but I donŽt know if this could affect "CR" signature check or efi binary at all.

The normal edk2 code always uses the EFI types that are defined in https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/MdePkg/Include/X64/ProcessorBind.h etc. So I would not expect an issue.

I guess the StdLib probably has code that uses int and long and maybe there is a bug if it gets converted to an EFI type based on the compiler that is used. Seems like most cases simple casts would fix this?

Post by Cristiano Fernandes
IŽm using GCC44 on a Fedora 16 X64.
Thanks in advance,
--
Cristiano Fernandes
------------------------------------------------------------------------------
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure_______________________________________________
edk2-devel mailing list
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[Cristiano Fernandes]

Hi Andrew,

After doing some tests, I have manually set -mabi=ms in Conf/tools_def.txt:

*_GCC44_X64_ASLCC_FLAGS = DEF(GCC_ASLCC_FLAGS) -m64 -mabi=ms
*_GCC44_X64_ASM_FLAGS = DEF(GCC44_ASM_FLAGS) -m64 -mabi=ms
-melf_x86_64

This seems to solve the problem.
Now IŽm able to use StdLib with sockets with no problem.

Thanks,

Post by Cristiano Fernandes
Hi all,
IŽm trying to build a simple tcp echo server application using StdLib.
Works fine.
Works fine.
I get an ASSERT error (ASSERT
CR has Bad Signature) which ends on CpuDeadLoop().
An error like this usually means either the passed in pointer was not
valid, or data corruption has happened. You could add some DEBUG prints of
the structure to see if is wrong or corrupt?
This brings up something I've been thinking about. It would be useful to
have a version of the DEBUG print that does a hex dump. Maybe
DEBUG_HEX_DUMP (address, size)
00000000 23 0a 23 20 43 6f 70 79 72 69 67 68 74 20 28 63 |#.# Copyright (c|
00000010 29 20 32 30 30 36 20 2d 20 32 30 31 30 2c 20 49 |) 2006 - 2010, I|
00000020 6e 74 65 6c 20 43 6f 72 70 6f 72 61 74 69 6f 6e |ntel Corporation|
00000030 2e 20 41 6c 6c 20 72 69 67 68 74 73 20 72 65 73 |. All rights res|
00000040 65 72 76 65 64 2e 3c 42 52 3e 0a 23 20 54 68 69 |erved.<BR>.# Thi|
This would be helpful in debugging memory corruption issues. What do folks think?
The first think that came to my mind is the difference between LP64
(Linux) and LLP64 (Windows), but I donŽt know if this could affect "CR"
signature check or efi binary at all.
The normal edk2 code always uses the EFI types that are defined in
https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/MdePkg/Include/X64/ProcessorBind.hetc. So I would not expect an issue.
I guess the StdLib probably has code that uses int and long and maybe
there is a bug if it gets converted to an EFI type based on the compiler
that is used. Seems like most cases simple casts would fix this?
IŽm using GCC44 on a Fedora 16 X64.
Thanks in advance,
--
Cristiano Fernandes
------------------------------------------------------------------------------
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure_______________________________________________
edk2-devel mailing list
https://lists.sourceforge.net/lists/listinfo/edk2-devel
------------------------------------------------------------------------------
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
edk2-devel mailing list
https://lists.sourceforge.net/lists/listinfo/edk2-devel