Re: [Edk2 Dev] GCC toolchain status

Subject: Re: [Edk2 Dev] GCC toolchain status

From: "Brian J. Johnson" <bjohnson@sgi.com>

To: dev@edk2.tianocore.org

Date: 2008-10-08 21:14:23

Randy Thelen wrote:
> Tristan Gingold wrote:
> 
>> Using EDK2 and the GNU toolchain, I have able to boot Linux on x86 and 
>> ia64
>> and OpenVMS on ia64.  For sure I mostly use EFI to boot OSes but it is
>> stable enough.
> 
> Let me turn this around.  When do you believe the stability of EDK2 
> would be of a high enough level that companies can start shipping 
> products based on it?
> 
> What are some of the impediments of getting to this stage?

Jumping in here to provide another view:

We are dependent on our independent BIOS vendor (IBV) for base BIOS code 
which we modify for our systems (massive servers using Xeon and IA64 
CPUs.)  Our IBV is our only source for modules that support Intel's CPUs 
and chipsets, as well as modules (such as a CSM) which we'd rather not 
write ourselves.

We get IBV code at a very late date in the product development cycle, 
and don't have time to mess with details like porting it to a different 
compiler or build environment.  Therefore we have to use whatever they 
give us, and they (in turn) basically have to use whatever Intel gives 
them.  To date, this has been EDK1.  We keep pushing them and Intel to 
move to EDK2, but they have been unwilling to make that switch (although 
Intel did do one IA64 platform on EDK2.)

Besides, there are Microsoft-isms scattered throughout the IBV code 
(MASM assembler syntax, case-insensitive #include file names, MS 
compiler #pragmas, Windows-only binary build tools, etc.) which make it 
difficult to port the platform code to EDK2 and/or gcc.  So even if we 
did decide to do the port ourselves, we would have a nightmare of a time 
managing updates.

So until the entire pipeline from UEFI->TianoCore->Intel->IBV->us gets 
filled with EDK2 code, we're stuck on EDK1 and MS tools.

> One more question that leaps to mind is: given that there is a large 
> disparity between the size of GNU toolchain created images vs. VS200x 
> created images, would a development cycle of using GNU for dev and VS 
> for release (both to QA and to customers) make sense?

Code size isn't an issue for us... we have really big flash chips.  But 
even if we didn't, we wouldn't consider using different compilers for 
development and release.  Way, way, way too much risk.

> What are you all doing in terms of debugging VS built EFI?  Have you 
> purchased a debugger on the open market (if so, whose?) or do you just 
> add print statements, rebuild, run, and repeat?

I've searched high and low for some way to use VS's .pdb symbol files 
with gdb, and it doesn't seem to exist.  Winelib has open-source code 
for parsing .pdb data, but no one seems to have integrated it with gdb 
(or written a .pdb to DWARF or stabs translator.)

I've also searched for an source-level implementation of a ROMmable stub 
for MS's remote debug protocol, so I could use VS's debugger on our 
platform.  That doesn't seem to exist either.

Simulators, ITPs, and printfs are your friends....
-- 

						Brian

--------------------------------------------------------------------

    "Partly cloudy with rain and snow"
                                        -- Badger Hearald weather forecast
                                           4/20/93 (And they were right!)

------------------------------------------------------
https://edk2.tianocore.org/ds/viewMessage.do?dsForumId=135&dsMessageId=30039

To unsubscribe from this discussion, e-mail: [dev-unsubscribe@edk2.tianocore.org].