Laszlo Ersek [mailto:ler...@redhat.com] wrote:
]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. Release builds are/were shipped out of necessity, at least in the past. This was due to a desire to cut board cost by using the smallest possible flash chip. But times are changing and NOR flash capacity is growing even faster than code size. So the flash size reduction motivation for optimizing code is losing importance I guess. In my experience, getting a release build to work sometimes results in uncovering hidden coding errors. A bigger reason to use release builds is boot time reduction. While UEFI will never boot as fast as coreboot, it can narrow the gap some by minimizing the time spent reading data from the flash chip. Adding -Os and link time optimization can cut the image size in half. That saves significant time when the image is read from the flash chip. ] ]> 2) Why is the NOOPT build missing from virtually every DSC file in EDK2? ] ]I guess in OVMF we never needed it? I got OVMF booting on a real server a few years ago. Adding the NOOPT build was the first thing I did. That let me step through the source code and see all local variables. I couldn't have gotten it working as quickly as I did without source level debugging. Instead of adding NOOPT to every project, adding it to one or two might be a better idea. I don't want to see a lot of code change just for the sake debugger support. ]> 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. I understand. But Microsoft tool chains are still supported by the EDK2 project. Dropping support for Microsoft tool chains would solve some problems. But clearly that isn't going to happen any time soon. It is surprising to see the strength and weaknesses of different tool chains. Microsoft perfected link time optimization 10+ years ago. Yet they didn't even bother with C99 support until recently. GCC had C99 10+ years ago, yet only recently perfected link time optimization. It is unfortunate there is no nice open source debugger for use with EDK2 and other embedded projects. Some of the OEM and IBV debuggers I used were really nice, though at the time they supported only Microsoft debug symbols. ]> 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. Of all EDK2 projects, Duet seems to need the fewest changes for use on real hardware. You would be surprised to know how many Duet based systems have shipped from tier one oems. ]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 ------------------------------------------------------------------------------ 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
