On May 28, 2013, at 2:32 PM, Jordan Justen <jljus...@gmail.com> wrote:
> On Tue, May 28, 2013 at 12:26 PM, Andrew Fish <af...@apple.com> wrote: >> On May 28, 2013, at 12:10 PM, Jordan Justen <jljus...@gmail.com> wrote: >>>> Anyway, I am not sure GCC for ARM architectures supports PE/COFF (I guess >>>> that would 'only' required to add the PE/COFF relocation symbols). But if >>>> ELFGCC is deprecated for IA32/X64 usage and ARM GCC only supports ELF >>>> output, do you see any issue to re-use ELFGCC as a cross-toolchain ? >>> >>> I don't think UEFI supports ELF images for any architecture. For that >>> reason, I don't think a toolchain named "*ELF*" is a good idea. >> >> Well the ELF bit is important as it has to do with which debugger you can >> use. It is the reason we compile to ELF and convert, so we can use debuggers >> that know about ELF images. >> >>> Maybe GCCCROSS is a better name? >> >> The problem is a gcc cross compiler could also directly produce a PE/COFF >> image, so which tool chain are you talking about? >> >> I vote to leave ELF in the name as it is the debug format being used. Well I >> guess we could call it DWARF to be pedantic, but Mach-O uses DWARF too, so >> ELF better maps what the debugger knows how to deal with. >> > > If the debugging format is the critical element, then maybe DWARFGCC > is the right answer. I don't agree with this though. It doesn't seem > to follow the model of VS*/GCC*. > Well one may expect the default to be the tools produce native EFI PE/COFF images, and if they don't we have a special name that is different. We use XCLANG for OS X and that is Mach-O wrapped DWARF, but that is our only option. I don't know what a good names is, and as I pointed out gdb has to be able to read both ELF and DWARF as the image format defines how to find the DWARF info. But all this may be too much info for the use? It is unclear the best way to explain this. Maybe gdb always supports ELF and ELF is thus redundant? > ELFGCC seems additionally problematic given its baggage as a 'hack' > toolchain for UnixPkg. I'd been hoping to deprecate it after > deprecating UnixPkg. (Hmm, probably time to follow through with that.) > Works for me. > Why this support can't be merged into the actively maintained GCC4* > toolchains? Or, will this introduce too much confusion on these > toolchains? > I think what we need to think about is how many copies of tools would I need to install to make all this work? So it seems that the native tools will end up in /usr/bin while the cross compilers will end up in some other location. So the requirement for a common name would be to support /usr/bin and maybe two cross compiler install locations. This implies we may need a per architecture tools path for something like GCC> > I like the CROSS_COMPILE idea, but maybe instead it should be TOOLS_PFX? > > Although, doesn't CROSS_COMPILE/TOOLS_PFX gloss over the fact that > changing the GCC version like this may mean changes are required to > the tool arguments? > Well it is probably better to create a new name when the change is required. It looks like VC++ changes its install location every release so you need a specific name. GCC is likely to change less often, so make a new name containing the version number when a new one is required? I started the Xcode numbering at the minimum version of Xcode required, and then converted to XCLANG for the move away from gcc. I may have to introduce numbers in the future if arguments change. > -Jordan ------------------------------------------------------------------------------ Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
