Jump to content

C++ proposition


Jief_Machak
 Share

823 posts in this topic

Recommended Posts

The "if ( EntryC->getREFIT_MENU_SWITCH() )" missing appears in my commit : "Big big refactoring of REFIT_MENU structs."

 

Again, it's funny that it's working in VMWare. Good I have a working setup in QEMU, who traps more things.

Link to comment
Share on other sites

1 hour ago, Jief_Machak said:

Have you tried ?

Here is my compilation.

CLOVER.efi

Sorry for the delay. Yes, your version works in windows QEMU.

Will test on real computer at the evening.

Now I am at Windows and will check VS compilation.

Pity.

Quote

CLOVER.lib(tool.obj) : fatal error LNK1237: during code generation, compiler introduced reference to symbol memset defined in module 'CLOVER.lib(memory.obj)' compiled with /GL

May be exclude option /GL?

There is also Microsoft invention

#pragma function(memset...)

but I still don't understand how to use it.

Link to comment
Share on other sites

17 hours ago, Jief_Machak said:

I think I got it. Possible to keep /GL if we add  /INCLUDE:memset as an option for the linker. I don't know how to do that from refit.inf

I tried "MSFT:*_*_*_SLINK_FLAGS = /INCLUDE:memset".

 

 

I'm starting to understand that memset is optimized out, but not if you use /INCLUDE. I just didn't know where to put it.

 

DON'T expect to run. I still don't know if things are properly initialised in VS.

Link to comment
Share on other sites

Text is not properly initialized which leads to loose fonts navigating menu. I have enough time to see if Clover somehow works.

 

I read that

#pragma intrinsic(memset)

will produce inline function? It will be a solution. Will check.

 

Now I have memset generated in just three places:

legacy.cpp ; 122  :   Entry = new LEGACY_ENTRY();

legacy.cpp ; 168  :   SubEntry =  new LEGACY_ENTRY();

tools.cpp ; 87   :   Entry = new REFIT_MENU_ENTRY_LOADER_TOOL();

other cases gone. Why? There are no more memset generation at new LOADER_ENTRY(). Because there is a constructor?

Link to comment
Share on other sites

For me, a generated memset is because there is no ctor. I tried yesterday or day before but with no luck.

If you're sure that no memset is called when doing new LOADER_ENTRY(), try by adding "  LEGACY_ENTRY() : REFIT_MENU_ITEM_ABSTRACT_ENTRY_LOADER() {};" in LEGACY_ENTRY.

Tell me if you got a memset call then.

It's anyway good practice to not rely on implicit ctor. So let's define them anyway.

 

Link to comment
Share on other sites

53 minutes ago, Jief_Machak said:

For me, a generated memset is because there is no ctor. I tried yesterday or day before but with no luck.

If you're sure that no memset is called when doing new LOADER_ENTRY(), try by adding "  LEGACY_ENTRY() : REFIT_MENU_ITEM_ABSTRACT_ENTRY_LOADER() {};" in LEGACY_ENTRY.

Tell me if you got a memset call then.

It's anyway good practice to not rely on implicit ctor. So let's define them anyway.

 

Yes! It helps!

Now there is the last memset location in tool.cpp

Do the same?

Link to comment
Share on other sites

Here is new code disassembled

; 168  :   SubEntry =  new LEGACY_ENTRY();

  0041b	b9 98 00 00 00	 mov	 ecx, 152		; 00000098H
  00420	41 88 46 78	 mov	 BYTE PTR [r14+120], al
  00424	e8 00 00 00 00	 call	 ??2@YAPEAX_K@Z		; operator new
  00429	48 8b f0	 mov	 rsi, rax
  0042c	48 85 c0	 test	 rax, rax
  0042f	74 5b		 je	 SHORT $LN47@AddLegacyE
  00431	0f 57 c0	 xorps	 xmm0, xmm0
; File d:\projects\cloverbootloader\refit_uefi\gui\menu_items\menu_items.h

; 130  :   REFIT_ABSTRACT_MENU_ENTRY(CONST CHAR16 *Title_) : Title(Title_), Row(0), ShortcutDigit(0), ShortcutLetter(0), Image(NULL), Place({0,0,0,0}), AtClick(ActionNone), AtDoubleClick(ActionNone), AtRightClick(ActionNone), AtMouseOver(ActionNone), SubScreen(NULL) {};

  00434	4c 89 60 08	 mov	 QWORD PTR [rax+8], r12
  00438	0f 11 40 28	 movups	 XMMWORD PTR [rax+40], xmm0
  0043c	4c 89 60 10	 mov	 QWORD PTR [rax+16], r12
  00440	0f 57 c9	 xorps	 xmm1, xmm1
  00443	44 89 60 18	 mov	 DWORD PTR [rax+24], r12d
  00447	0f 11 48 38	 movups	 XMMWORD PTR [rax+56], xmm1
  0044b	4c 89 60 20	 mov	 QWORD PTR [rax+32], r12
  0044f	4c 89 60 48	 mov	 QWORD PTR [rax+72], r12
  00453	4c 89 60 50	 mov	 QWORD PTR [rax+80], r12
  00457	4c 89 60 58	 mov	 QWORD PTR [rax+88], r12

; 315  :                 : Volume(0), DevicePathString(0), LoadOptions(0), BootNum(0), LoaderPath(0), DriveImage(0), BadgeImage(0)

  0045b	4c 89 60 60	 mov	 QWORD PTR [rax+96], r12
  0045f	4c 89 60 68	 mov	 QWORD PTR [rax+104], r12
  00463	4c 89 60 70	 mov	 QWORD PTR [rax+112], r12
  00467	4c 89 60 78	 mov	 QWORD PTR [rax+120], r12
  0046b	4c 89 a0 80 00
	00 00		 mov	 QWORD PTR [rax+128], r12
  00472	4c 89 a0 88 00
	00 00		 mov	 QWORD PTR [rax+136], r12
  00479	4c 89 a0 90 00
	00 00		 mov	 QWORD PTR [rax+144], r12

; 363  :   //  UINTN             BootNum;

  00480	48 8d 05 00 00
	00 00		 lea	 rax, OFFSET FLAT:??_7LEGACY_ENTRY@@6B@
  00487	48 89 06	 mov	 QWORD PTR [rsi], rax

There is no memset. There are explicit assignments.

Link to comment
Share on other sites

12 minutes ago, Slice said:

Yes! It helps!

Now there is the last memset location in tool.cpp

Do the same?

Yes, at least a ctor (doesn't need to be one with no parameter). If I understand well, the compiler has to notice that we init all members, so it won't generate a memset to init a uninitialised member.

Link to comment
Share on other sites

41 minutes ago, Jief_Machak said:

How do you do theme switch ?

Options Menu -> GUI -> theme.

Returning to main menu (ESC,ESC,ESC) will switch theme.

But there are bugs with global variables so it should be revised.

 

I tested ScreenShot. It works!

#define USE_XIMAGE 1
#if USE_XIMAGE
EFI_STATUS egScreenShot(VOID)
{

using XStringW and XImage

Link to comment
Share on other sites

@Slice FYI : I had a problem. When compiled by GCC, the QEMU image you gave me boot to DUET. From there, I could go to Boot Maintenance Manager and select Boot from a file and it works !

A bit strange I'd say. And I remember to have that exact problem when I was looking for a solution to get PS2 keyboard for filevault (just before having the idea of AppleKeyFeeder).

I wanted you to know that I've replace to 'boot' file by one I just generated (well, not me but the edk build system :-) and it works. No more boot to duet (I can still access it if I want by exiting Clover).

I don't know if you got that problem.

In top of that, the QEMU screen is a bit smaller (before it was 80% of my screen), which is nice. And if you go to DUET, the response time is way better.

Just in case...

Link to comment
Share on other sites

MSVC's default constructor is a memset to zero the size of the object. So it will be generated if you don't have a constructor being used or if the default no argument constructor does not exist. You guys aren't using NULL in c++ are you? Because that causes a type casting error, you should be using nullptr as it will become whatever pointer type. NULL is technically some sized integer and there is no guarantee pointer size == any integer size.

 

EDIT: Grammar.

Edited by apianti
Link to comment
Share on other sites

2 hours ago, Jief_Machak said:

@Slice FYI : I had a problem. When compiled by GCC, the QEMU image you gave me boot to DUET. From there, I could go to Boot Maintenance Manager and select Boot from a file and it works !

A bit strange I'd say. And I remember to have that exact problem when I was looking for a solution to get PS2 keyboard for filevault (just before having the idea of AppleKeyFeeder).

I wanted you to know that I've replace to 'boot' file by one I just generated (well, not me but the edk build system :-) and it works. No more boot to duet (I can still access it if I want by exiting Clover).

I don't know if you got that problem.

In top of that, the QEMU screen is a bit smaller (before it was 80% of my screen), which is nice. And if you go to DUET, the response time is way better.

Just in case...

My boot file which is DUET with some modifications differs from EDK2 version first of all by default file name to boot. EDK2 started EFI/BOOT/BOOTX64.EFI while my DUET started /EFI/CLOVER/CLOVERX64.EFI.

 

QEMU screen depends on Clover set resolution. 

config.plist->GUI->ScreenResolution

I set 1024x768.

Link to comment
Share on other sites

I was talking about the resolution I had BEFORE clover. I had a small screen for Qemu text boot, then I got a very BIG screen and then, if Clover loads, I got the screen configured in config.plist.

And guess what, problem is back. When it's compiled with GCC, it's not booting automatically.

 

I'm having a look at BdsEntry, but I don't have any log. Must I activate something to get the log from Duet ?

Link to comment
Share on other sites

18 minutes ago, Jief_Machak said:

I was talking about the resolution I had BEFORE clover. I had a small screen for Qemu text boot, then I got a very BIG screen and then, if Clover loads, I got the screen configured in config.plist.

And guess what, problem is back. When it's compiled with GCC, it's not booting automatically.

 

I'm having a look at BdsEntry, but I don't have any log. Must I activate something to get the log from Duet ?

It is not a simple procedure. See BiosVideo produces a log inside DUET but it keeps the log in memory until Clover take it.

 

We forgot to start a mouse. Or may be it just not drawn. Should be tested separately.

 

Forgot to say that DUET is also set resolution. May be it is a reason why you got BIG screen. It is one of my patches to DUET.

Link to comment
Share on other sites

 Share

×
×
  • Create New...