Laszlo, Symbolic debugging should be fully supported at all optimization levels. The compiler/linker generates .pdb files for MSFT and .debug sections for GCC.
The purpose of NOOPT is not to support source level debug. It is to make debug easier. When optimizations are turned up, many of the call parameters and local variables can may be optimized into registers and calls can be inlined. Also, the same register may be used for multiple parameters or locals depending on how they are used in the function. Not all debuggers are aware of these register optimizations and may show incorrect values for parameters and locals. When a difficult bug is being evaluated, it is sometimes easier to make sure these register optimization are disabled and function inlining id disables so the debugger can show correct values for parameters and locals on every call in the call stack. In this case, a single module under debug may disable optimization in DSC <BuildOptions> or INF [BuildOptions], or if all modules need optimization disabled to debug across the entire call stack, NOOPT can be used. Best regards, Mike > -----Original Message----- > From: Laszlo Ersek [mailto:[email protected]] > Sent: Saturday, July 16, 2016 7:45 AM > To: Ard Biesheuvel <[email protected]> > Cc: [email protected] <[email protected]>; [email protected]; Gao, > Liming > <[email protected]>; Shi, Steven <[email protected]>; Zhu, Yonghong > <[email protected]>; Kinney, Michael D <[email protected]>; > Justen, > Jordan L <[email protected]>; Bruce Cran <[email protected]>; Paolo > Bonzini > <[email protected]>; Scott Duplichan <[email protected]> > Subject: Re: [PATCH v2 3/5] BaseTools/tools_def: enable Os optimization for > GCC X64 > builds > > On 07/16/16 14:58, Ard Biesheuvel wrote: > > > Bottom line is that I don't really care :-) -Os for RELEASE is a clear > > improvement. If nobody is doing source code level debugging using GCC > > builds, it appears to be an improvement for DEBUG as well. In any > > case, it would be good to have the numbers so we can make an informed > > decision. > > At this point you've sort of convinced me that we should add -Os to > DEBUG as well. It *doubly* aligns DEBUG_GCCxx_X64_CC_FLAGS with the > status quo: first with GCC+IA32, second with non-GCC+X64. > > The gdb setup for GCC+X64 is so contrived at the moment *anyway* that > removing -Os from the build flags as a further step is practically no > additional burden. If we become serious about it, we can always > introduce NOOPT later, further aligning GCC with other toolchains on > IA32 and X64. > > > Another thing I noticed: OpensslLib uses -UNO_BUILTIN_VA_ARGS to > > switch to the default va_list implementation, which is necessary since > > its variadic functions lack an EFIAPI annotation. This means I should > > probably revise the patch to allow the standard __builtins to be used, > > e.g., add -DNO_MS_ABI_VARARGS to OpensslLib instead, and make the use > > of __builtin_ms_va_list conditional on !defined(NO_MS_ABI_VARARGS) > > Aaargh. I've run into (independent) varargs problems with OpenSSL in > edk2 before, so I'm not sure how my testing missed this! > > Ah wait, I may know how -- I think I wanted to use EnrollDefaultKeys.efi > as a starting point for SB testing too, but I didn't get as far with it, > because -O2 in your v1 triggered a latent bug in the app. > > ... So, with your next update, we won't just distinguish "builtin" from > "no-builtin" for VA_LIST, we'll also distinguish "MS" from "SYSV" within > "builtin:. :( > > <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50818> just got twice as > annoying. :( :( > > I guess I'll delay my testing until your v3. Is that okay with you? > > Thanks > Laszlo _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
