On 11/07/14 21:29, Scott Duplichan wrote: > Jordan Justen [mailto:jordan.l.jus...@intel.com] wrote: > > ]On 2014-11-07 08:16:23, Scott Duplichan wrote: > ]> These are all good answers. I can't come up with a strong argument for the > ]> mixed sysv/ms ABI. Maybe the next step is to test -mabi=ms using several > gcc > ]> versions (I think -mabi=ms was introduced with gcc 4.5). If that works, I > could > ]> submit a patch and see what happens.. > ] > ]I mentioned a reason in this thread a few days back. But, we should > ]look into -mabi=ms for RELEASE builds. > ] > ]-Jordan > > I agree, the approach in your previous email is a good one. Prototyping > asm functions to enforce calling convention is always a good idea. In theory > an IA32 build could be done with a Microsoft compiler with option /Gr > (__fastcall calling convention) and it would work. This would not be possible > if asm function calling convention information were missing. If I make this > patch, I will add the gcc -mabi=ms to the release build. > > Now for rants... > 1) Why do so many developers never want to test release builds? To me, code > is not clean until both debug and release builds work smoothly.
In my experience, release (== optimized) builds are practically unsupportable. Even the Linux kernel disables some optimizations that make the disassembly unreadable. Unless stuff is power and/or performance critical, I prefer if the code does exactly what I tell it to do. (Case in point: the -Os bug with recursion + ellipsis. It works with -O0. Compilers have bugs.) *All* software is chock full of bugs, and having to figure out what goes wrong at a customer's site is a question of "when", not "if". They either won't be able, or willing, to attempt to reproduce the issue with a debug build, or they will try and the bug might disappear. Consequently, since I'm not keen on shipping anything but a debug build, I don't feel like putting many resources into release builds. > 2) Why is the NOOPT build missing from virtually every DSC file in EDK2? I guess in OVMF we never needed it? > The EDK NOOPT build is most like what developers call a DEBUG build. It is > the only one setup for source level debugging, at least for Microsoft tool > chains. I don't use Microsoft tool chains. And source level debugging with gdb is hardly possible even on DEBUG; you have to jump through incredible hoops. NOOPT doesn't solve anything for Linux-based developers & users of OVMF. > The Duet DSC files are missing both RELEASE and NOOPT options. It's an emulator platform, isn't it? You probably won't use it in production. Thanks Laszlo ------------------------------------------------------------------------------ Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
