Hi Giri, Responses below.
Mike > -----Original Message----- > From: Mudusuru, Giri P > Sent: Sunday, July 17, 2016 9:58 AM > To: Laszlo Ersek <[email protected]>; Kinney, Michael D > <[email protected]>; > Ard Biesheuvel <[email protected]> > Cc: Bruce Cran <[email protected]>; Scott Duplichan <[email protected]>; > Justen, Jordan > L <[email protected]>; [email protected] > <[email protected]>; > [email protected]; Gao, Liming <[email protected]>; Paolo Bonzini > <[email protected]> > Subject: RE: [edk2] [PATCH v2 3/5] BaseTools/tools_def: enable Os > optimization for GCC > X64 builds > > Here is the summary of discussion I understand from this thread > > -RELEASE - Debug logs are OFF, Optimization ON, Symbolic debug OFF > -DEBUG - Debug logs are ON, Optimization ON, Symbolic debug ON > -NOOPT - Debug logs are ON, Optimization OFF, Symbolic debug ON These are BUILDTARGET names. Logging is an independent feature from these BUILDTARGET names. A BUILDTARGET is specified using the -b flag to build.exe and selects compiler/linker flags from Conf/tools_def.txt. > > Use case for enabling symbolic debug on release mode could be during debug of > timing > related bugs where enabling debug logs resolves the issues. In this use case > we might > want Symbolic debug on RELEASE build also. Since LOGGING is an independent feature, you would debug this with DEBUG enabled. > > Use case for disable optimization on release mode is to debug some compiler > optimization issues, in which we might need to disable optimization in > release mode. This would only be a temporary workaround. You should always root cause failures that only show up when optimization is enabled. It usually indicates a logic bug or race condition that needs to be resolved. > > As long as we have independent control of Debug Logs, Optimization and > Symbolic debug > we can have any possible combination. Agreed. > > How about we have -RELEASE and -DEBUG (same as discussed and most commonly > used) > > -RELEASE - Debug logs are OFF, Optimization ON, Symbolic debug OFF > -DEBUG - Debug logs are ON, Optimization ON, Symbolic debug ON I disagree. DEBUG as a BUILDTARGET means symbolic debug. The use of DEBUG to also mean logging has been a practice I have observed for platforms, but that is overloading the meaning of a BUILDTARGET that is used to select different compiler/linker flags. I recommend adding a flag called LOGGING so LOGGING can be enabled/disabled independent of symbolic debug. > > and independent flags for -NOOPT and -SOURCE_DEBUG (Symbolic debug) as two > independent > options for special debug purposes? SOURCE_DEBUG_ENABLE is yet another independent feature. DEBUG means symbols should be generated and the PE/COFF image should contains a debug directory entry that is a file path to the symbol file (e.g. PDB for MSFT ) on the host system. When the UDK Debugger Tool is used to support source level debug using WinDbg or GDB and a UART or other serial stream device between a host and target, a debug agent must be built into the target FW image. SOURCE_DEBUG_ENABLE is the feature name that can be used to enable/disable the addition of the debug agent. So in the end, there really are 5 flags involved to get all the combinations Build.exe -b flag (pick one of) DEBUG RELEASE NOOPT Define names (all 4 combinations supported) LOGGING SOURCE_DEBUG_ENABLE This means there are 12 combinations of these flags. It does not make sense to use a BUILDTARGET of RELEASE with SOURCE_DEBUG_ENABLE set. So 10 combinations are meaningful. BUILDTARGET LOGGING SOURCE_DEBUG_ENABLE =========== ======== =================== RELEASE Disabled Disabled No log messages and compiler optimizations enabled. RELEASE Disabled Enabled N/A (UDK Debugger Tool should work, but would only show disassembly without symbols) RELEASE Enabled Disabled Logging messages enabled and compiler optimizations enabled. RELEASE Enabled Enabled N/A (UDK Debugger Tool should work, but would only show disassembly without symbols) DEBUG Disabled Disabled Symbolic debug using JTAG. Compiler optimizations enabled. DEBUG Disabled Enabled Symbolic debug using the UDK Debugger Tool. Compiler Optimizations enabled. DEBUG Enabled Disabled Symbolic debug using JTAG with log messages. Compiler Optimizations enabled. DEBUG Enabled Enabled Symbolic debug using the UDK Debugger Tool with log messages. Compiler Optimizations enabled. NOOPT Disabled Disabled Symbolic debug using JTAG. Compiler optimizations disabled. NOOPT Disabled Enabled Symbolic debug using the UDK Debugger Tool. Compiler Optimizations disabled. NOOPT Enabled Disabled Symbolic debug using JTAG with log messages. Compiler Optimizations disabled. NOOPT Enabled Enabled Symbolic debug using the UDK Debugger Tool with log messages. Compiler Optimizations disabled. Each platform can choose which of these 12 combinations are actually validated and supported on different tool chains and debuggers. > > Thanks, > -Giri > > > -----Original Message----- > > From: edk2-devel [mailto:[email protected]] On Behalf Of > > Laszlo Ersek > > Sent: Saturday, July 16, 2016 11:22 AM > > To: Kinney, Michael D <[email protected]>; Ard Biesheuvel > > <[email protected]> > > Cc: Bruce Cran <[email protected]>; Scott Duplichan <[email protected]>; > > Justen, Jordan L <[email protected]>; [email protected] > > <[email protected]>; [email protected]; Gao, Liming > > <[email protected]>; Paolo Bonzini <[email protected]> > > Subject: Re: [edk2] [PATCH v2 3/5] BaseTools/tools_def: enable Os > > optimization for GCC X64 builds > > > > On 07/16/16 19:43, Kinney, Michael D wrote: > > > 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. > > > > I may not have used the correct terminology, but the case when -b DEBUG > > enables the intrusive optimizations that you describe (i.e., the source > > code cannot be uniquely matched to the firmware state) is practically > > undistinguishable from the case when no debug symbols exist at all. It > > is unusable for analysis with sufficient detail. > > > > In that sense, to me at least, the difference between DEBUG and NOOPT is > > not "symbolic debugging is hard or easy"; it is "symbolic debugging is > > unusable (as if the symbols don't exist) vs. fully supported". > > > > Like everyone else, I've debugged normal Linux userspace processes that > > were built with "-g -O2", and their core dumps are useless for any > > efficient purposes. One is able to narrow it down to a more or less > > tight function context, but for understanding local variables, one has > > to look at registers and disassembly (and even that isn't guaranteed to > > produce results). Single stepping simply doesn't work; gcc can routinely > > reorder the assembly so that it loses any resemblance with the original > > code (the Linux kernel disables some of these gcc optimization features > > individually). So, as far as I'm concerned, symbolic debugging is > > entirely defeated by -O2 or -Os, regardless of -g. This is why I equate > > > > - NOOPT to "symbolic debug works" > > - DEBUG to "symbolic debug doesn't work, but ASSERT() and friends do" > > - RELEASE to "neither of those work". > > > > > 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. > > > > This is something that I expect by default from a binary whose build > > options are supposed to support symbolic debugging. > > > > > 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. > > > > I accept that your description defines the official meaning for NOOPT / > > DEBUG / RELEASE, and I thank you for educating me on them. For practical > > purposes though, I'll have to stick with my (non-official) definitions > > -- if we add -Os to DEBUG (and I don't mind if we do), then to me > > personally, it won't be suitable for source level debugging. Only NOOPT > > will be (to be added later). > > > > Thanks! > > Laszlo > > > > > 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 _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
