Re: [edk2] [PATCH v2 00/16] unify GCC command line options

[Ard Biesheuvel]

On 8 October 2015 at 21:56, Bill Paul  wrote:
> Of all the gin joints in all the towns in all the world, Bill Paul had to walk
> into mine at 10:30:26 on Monday 24 August 2015 and say:
>
>> Of all the gin joints in all the towns in all the world, Ard Biesheuvel had
>> to
>>
>> walk into mine at 10:22:59 on Monday 24 August 2015 and say:
>> > On 24 August 2015 at 19:20, Bill Paul  wrote:
>> > > Of all the gin joints in all the towns in all the world, Ard Biesheuvel
>> > > had to
>> > >
>> > > walk into mine at 10:06:10 on Monday 24 August 2015 and say:
>> > >> On 24 August 2015 at 19:02, Bill Paul  wrote:
>> > >> > Of all the gin joints in all the towns in all the world, Ard
>> > >> > Biesheuvel had to
>> >
>> > >> > walk into mine at 09:54:08 on Monday 24 August 2015 and say:
>> > [...]
>> >
>> > >> >> Jordan suggested to drop UNIXGCC as well, and introduce MINGW
>> > >> >> instead iff we want the MinGW PE/COFF GCC, and I think we do, if
>> > >> >> only so that we have a LLP64 environment for X64 available to
>> > >> >> those without the possibility or the desire to run a MS toolchains
>> > >> >> under Windows.
>> > >> >
>> > >> > People should be able to build a known-good crossbuild toolchain.
>> > >> > This is the simplest way to provide that option.
>> > >>
>> > >> Meh. The primary audience of this feature are people building UEFI for
>> > >> X64 on X64, in which case the GCC4x options are arguably simpler. But
>> > >> apparently we agree that we should keep it /and/ support it.
>> > >>
>> > >> > By the way, do you think I can get you to update the
>> > >> > mingw-gcc-build.py script while you're at it? :)
>> > >>
>> > >> I proposed some updates here
>> > >> http://thread.gmane.org/gmane.comp.bios.edk2.devel/1297
>> > >> (with you on cc). Care to ack those?
>> > >
>> > > Is there a particular reason why you chose to use binutils from
>> > > www.kernel.org rather than from ftpmirror.gnu.org (other than "that's
>> > > what it was doing before")?
>> >
>> > Nope, that was it :-)
>> >
>> > In fact, I vaguely remember noticing the kernel.org URL and thinking
>> > "hmm that's odd" but for some reason, it did not provoke any action on
>> > my part
>>
>> My attention was drawn to it before because the specific version the script
>> was looking for previously ceased to exist on www.kernel.org, which broke
>> the script.
>>
>> > > In my testing I used binutins 2.25 from gnu.org, and it worked ok. I
>> > > thought it made more sense to get both packages from the same place.
>> > >
>> > > source_files_common = {
>> > >
>> > > 'binutils': {
>> > >
>> > > 'url': 'http://ftpmirror.gnu.org/binutils/' + \
>> > >
>> > >'binutils-$version.tar.bz2',
>> > >
>> > > 'version': '2.25',
>> > > 'md5': 'd9f3303f802a5b6b0bb73a335ab89d66',
>> > > },
>> > >
>> > > }
>> >
>> > Yes, 2.25 would be even better. In fact, it might make sense to wait
>> > for 2.26 to appear, since it adds support for --gc-sections (see the
>> > other part of this thread) which brings performance of mingw in line
>> > with ELF based GCC regarding code size.
>>
>> Fair enough, as long as we don't have to wait too long. In any case, aside
>> from this, the changes look ok to me.
>>
>> -Bill
>
> So... about that "as long as we don't have to wait too long" thing? I think
> it's been too long. :)
>

Well, we never decided the 'UNIXGCC shall remain at the same
GCC/binutils version into eternity' vs 'UNIXGCC shall reflect the
current stable combo of GCC/binutils' debate, and to be honest, I kind
of lost interest, since my primary focus is AARCH64/ARM and
apparently, nobody else cares about UNIXGCC anyway (except Dave
perhaps?)

Apparently, for some reason, Larry Hauch needs to give his blessing if
we decide to change anything at all in this regard, but his name does
not come up in the git log for over a year, and I don't think I ever
saw emails from him on the list. So it is really a matter of deciding
whether toolchains tags have immutable versions associated with them
or not.

-- 
Ard.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 00/16] unify GCC command line options

[Bill Paul]

Of all the gin joints in all the towns in all the world, Bill Paul had to walk 
into mine at 10:30:26 on Monday 24 August 2015 and say:

> Of all the gin joints in all the towns in all the world, Ard Biesheuvel had
> to
> 
> walk into mine at 10:22:59 on Monday 24 August 2015 and say:
> > On 24 August 2015 at 19:20, Bill Paul  wrote:
> > > Of all the gin joints in all the towns in all the world, Ard Biesheuvel
> > > had to
> > > 
> > > walk into mine at 10:06:10 on Monday 24 August 2015 and say:
> > >> On 24 August 2015 at 19:02, Bill Paul  wrote:
> > >> > Of all the gin joints in all the towns in all the world, Ard
> > >> > Biesheuvel had to
> > 
> > >> > walk into mine at 09:54:08 on Monday 24 August 2015 and say:
> > [...]
> > 
> > >> >> Jordan suggested to drop UNIXGCC as well, and introduce MINGW
> > >> >> instead iff we want the MinGW PE/COFF GCC, and I think we do, if
> > >> >> only so that we have a LLP64 environment for X64 available to
> > >> >> those without the possibility or the desire to run a MS toolchains
> > >> >> under Windows.
> > >> > 
> > >> > People should be able to build a known-good crossbuild toolchain.
> > >> > This is the simplest way to provide that option.
> > >> 
> > >> Meh. The primary audience of this feature are people building UEFI for
> > >> X64 on X64, in which case the GCC4x options are arguably simpler. But
> > >> apparently we agree that we should keep it /and/ support it.
> > >> 
> > >> > By the way, do you think I can get you to update the
> > >> > mingw-gcc-build.py script while you're at it? :)
> > >> 
> > >> I proposed some updates here
> > >> http://thread.gmane.org/gmane.comp.bios.edk2.devel/1297
> > >> (with you on cc). Care to ack those?
> > > 
> > > Is there a particular reason why you chose to use binutils from
> > > www.kernel.org rather than from ftpmirror.gnu.org (other than "that's
> > > what it was doing before")?
> > 
> > Nope, that was it :-)
> > 
> > In fact, I vaguely remember noticing the kernel.org URL and thinking
> > "hmm that's odd" but for some reason, it did not provoke any action on
> > my part
> 
> My attention was drawn to it before because the specific version the script
> was looking for previously ceased to exist on www.kernel.org, which broke
> the script.
> 
> > > In my testing I used binutins 2.25 from gnu.org, and it worked ok. I
> > > thought it made more sense to get both packages from the same place.
> > > 
> > > source_files_common = {
> > > 
> > > 'binutils': {
> > > 
> > > 'url': 'http://ftpmirror.gnu.org/binutils/' + \
> > > 
> > >'binutils-$version.tar.bz2',
> > > 
> > > 'version': '2.25',
> > > 'md5': 'd9f3303f802a5b6b0bb73a335ab89d66',
> > > },
> > > 
> > > }
> > 
> > Yes, 2.25 would be even better. In fact, it might make sense to wait
> > for 2.26 to appear, since it adds support for --gc-sections (see the
> > other part of this thread) which brings performance of mingw in line
> > with ELF based GCC regarding code size.
> 
> Fair enough, as long as we don't have to wait too long. In any case, aside
> from this, the changes look ok to me.
> 
> -Bill

So... about that "as long as we don't have to wait too long" thing? I think 
it's been too long. :)

-Bill

-- 
=
-Bill Paul(510) 749-2329 | Senior Member of Technical Staff,
 wp...@windriver.com | Master of Unix-Fu - Wind River Systems
=
   "I put a dollar in a change machine. Nothing changed." - George Carlin
=
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 00/16] unify GCC command line options

[Ard Biesheuvel]

On 24 August 2015 at 19:20, Bill Paul wp...@windriver.com wrote:
 Of all the gin joints in all the towns in all the world, Ard Biesheuvel had to
 walk into mine at 10:06:10 on Monday 24 August 2015 and say:

 On 24 August 2015 at 19:02, Bill Paul wp...@windriver.com wrote:
  Of all the gin joints in all the towns in all the world, Ard Biesheuvel
  had to
 
  walk into mine at 09:54:08 on Monday 24 August 2015 and say:
[...]
  Jordan suggested to drop UNIXGCC as well, and introduce MINGW instead
  iff we want the MinGW PE/COFF GCC, and I think we do, if only so that
  we have a LLP64 environment for X64 available to those without the
  possibility or the desire to run a MS toolchains under Windows.
 
  People should be able to build a known-good crossbuild toolchain. This is
  the simplest way to provide that option.

 Meh. The primary audience of this feature are people building UEFI for
 X64 on X64, in which case the GCC4x options are arguably simpler. But
 apparently we agree that we should keep it /and/ support it.

  By the way, do you think I can get you to update the mingw-gcc-build.py
  script while you're at it? :)

 I proposed some updates here
 http://thread.gmane.org/gmane.comp.bios.edk2.devel/1297
 (with you on cc). Care to ack those?

 Is there a particular reason why you chose to use binutils from www.kernel.org
 rather than from ftpmirror.gnu.org (other than that's what it was doing
 before)?

Nope, that was it :-)

In fact, I vaguely remember noticing the kernel.org URL and thinking
hmm that's odd but for some reason, it did not provoke any action on
my part

 In my testing I used binutins 2.25 from gnu.org, and it worked ok. I
 thought it made more sense to get both packages from the same place.

 source_files_common = {
 'binutils': {
 'url': 'http://ftpmirror.gnu.org/binutils/' + \
'binutils-$version.tar.bz2',
 'version': '2.25',
 'md5': 'd9f3303f802a5b6b0bb73a335ab89d66',
 },
 }


Yes, 2.25 would be even better. In fact, it might make sense to wait
for 2.26 to appear, since it adds support for --gc-sections (see the
other part of this thread) which brings performance of mingw in line
with ELF based GCC regarding code size.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 00/16] unify GCC command line options

[Bill Paul]

Of all the gin joints in all the towns in all the world, Ard Biesheuvel had to 
walk into mine at 10:06:10 on Monday 24 August 2015 and say:

 On 24 August 2015 at 19:02, Bill Paul wp...@windriver.com wrote:
  Of all the gin joints in all the towns in all the world, Ard Biesheuvel
  had to
  
  walk into mine at 09:54:08 on Monday 24 August 2015 and say:
  On 19 August 2015 at 00:27, Laszlo Ersek ler...@redhat.com wrote:
   On 08/18/15 22:04, Paolo Bonzini wrote:
   On 18/08/2015 08:52, Ard Biesheuvel wrote:
   Personally, I would not mind deprecating GCC44, but the biggest
   question I would have is what toolchains do the latest UDK releases
   claim to support.
   
   We also have the issue that every time I ask about deprecating a
   toolchain, Larry looks at me like I'm crazy. :)
   
   Well, perhaps he can chime in and explain his motivation behind
   this? At some point, we need to start removing things, surely.
   Larry just has a higher tolerance for pain :-)
   
   RHEL 6 is shipping GCC 4.4.  True, there are software collections to
   overcome that, but I think supporting GCC 4.4 is a good idea for at
   least a couple more years.
   
   Laszlo, do you still use RHEL 6?  Are you building with GCC 4.4?
   
   My laptop dual-boots RHEL-6 and RHEL-7, but I only use RHEL-6 when I
   need to work on RHEL-6 qemu-kvm or the RHEL-6 kernel. Which is
   nowadays practically never, thankfully.
   
   In addition, I couldn't sensibly *test* OVMF on a RHEL-6 host, because
   the RHEL-6 components lack support for the pflash-backed varstore.
   Which, for me at least, makes *building* OVMF on RHEL-6 kinda moot
   too.
   
   I have a number of Fedora virtual machines just for build-testing with
   gcc-4.4..gcc-4.9, but they are the consequence of the edk2 compiler
   support, not the reason for it. :)
   
   So, I'm in favor of dropping gcc-4.4 support. (In Fedora release
   terms, gcc-4.4 corresponds to fc13.)
  
  OK, so [supposedly] Larry is the only one who objects to deprecating
  toolchains, but since he has not responded to the suggestion, I think
  we should proceed anyway.
  
  I will respin this series, and instead of bringing CYGGCC and ELFGCC
  etc in line, I will propose to move them to tools_def.attic or
  whichever name is preferred by the group.
  
  Jordan suggested to drop UNIXGCC as well, and introduce MINGW instead
  iff we want the MinGW PE/COFF GCC, and I think we do, if only so that
  we have a LLP64 environment for X64 available to those without the
  possibility or the desire to run a MS toolchains under Windows.
  
  People should be able to build a known-good crossbuild toolchain. This is
  the simplest way to provide that option.
 
 Meh. The primary audience of this feature are people building UEFI for
 X64 on X64, in which case the GCC4x options are arguably simpler. But
 apparently we agree that we should keep it /and/ support it.
 
  By the way, do you think I can get you to update the mingw-gcc-build.py
  script while you're at it? :)
 
 I proposed some updates here
 http://thread.gmane.org/gmane.comp.bios.edk2.devel/1297
 (with you on cc). Care to ack those?

Is there a particular reason why you chose to use binutils from www.kernel.org 
rather than from ftpmirror.gnu.org (other than that's what it was doing 
before)? In my testing I used binutins 2.25 from gnu.org, and it worked ok. I 
thought it made more sense to get both packages from the same place.

source_files_common = {
'binutils': {
'url': 'http://ftpmirror.gnu.org/binutils/' + \
   'binutils-$version.tar.bz2',
'version': '2.25',
'md5': 'd9f3303f802a5b6b0bb73a335ab89d66',
},
}

-Bill

 Thanks,
 Ard.

-- 
=
-Bill Paul(510) 749-2329 | Senior Member of Technical Staff,
 wp...@windriver.com | Master of Unix-Fu - Wind River Systems
=
   I put a dollar in a change machine. Nothing changed. - George Carlin
=
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 00/16] unify GCC command line options

[Ard Biesheuvel]

On 19 August 2015 at 00:27, Laszlo Ersek ler...@redhat.com wrote:
 On 08/18/15 22:04, Paolo Bonzini wrote:


 On 18/08/2015 08:52, Ard Biesheuvel wrote:
 Personally, I would not mind deprecating GCC44, but the biggest
 question I would have is what toolchains do the latest UDK releases
 claim to support.

 We also have the issue that every time I ask about deprecating a
 toolchain, Larry looks at me like I'm crazy. :)

 Well, perhaps he can chime in and explain his motivation behind this?
 At some point, we need to start removing things, surely. Larry just
 has a higher tolerance for pain :-)

 RHEL 6 is shipping GCC 4.4.  True, there are software collections to
 overcome that, but I think supporting GCC 4.4 is a good idea for at
 least a couple more years.

 Laszlo, do you still use RHEL 6?  Are you building with GCC 4.4?

 My laptop dual-boots RHEL-6 and RHEL-7, but I only use RHEL-6 when I
 need to work on RHEL-6 qemu-kvm or the RHEL-6 kernel. Which is nowadays
 practically never, thankfully.

 In addition, I couldn't sensibly *test* OVMF on a RHEL-6 host, because
 the RHEL-6 components lack support for the pflash-backed varstore.
 Which, for me at least, makes *building* OVMF on RHEL-6 kinda moot too.

 I have a number of Fedora virtual machines just for build-testing with
 gcc-4.4..gcc-4.9, but they are the consequence of the edk2 compiler
 support, not the reason for it. :)

 So, I'm in favor of dropping gcc-4.4 support. (In Fedora release terms,
 gcc-4.4 corresponds to fc13.)


OK, so [supposedly] Larry is the only one who objects to deprecating
toolchains, but since he has not responded to the suggestion, I think
we should proceed anyway.

I will respin this series, and instead of bringing CYGGCC and ELFGCC
etc in line, I will propose to move them to tools_def.attic or
whichever name is preferred by the group.

Jordan suggested to drop UNIXGCC as well, and introduce MINGW instead
iff we want the MinGW PE/COFF GCC, and I think we do, if only so that
we have a LLP64 environment for X64 available to those without the
possibility or the desire to run a MS toolchains under Windows.

GCC44 could perhaps be moved to the attic as well, but it does not
need to be in this series imo

-- 
Ard.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 00/16] unify GCC command line options

[Bill Paul]

Of all the gin joints in all the towns in all the world, Ard Biesheuvel had to 
walk into mine at 09:54:08 on Monday 24 August 2015 and say:

 On 19 August 2015 at 00:27, Laszlo Ersek ler...@redhat.com wrote:
  On 08/18/15 22:04, Paolo Bonzini wrote:
  On 18/08/2015 08:52, Ard Biesheuvel wrote:
  Personally, I would not mind deprecating GCC44, but the biggest
  question I would have is what toolchains do the latest UDK releases
  claim to support.
  
  We also have the issue that every time I ask about deprecating a
  toolchain, Larry looks at me like I'm crazy. :)
  
  Well, perhaps he can chime in and explain his motivation behind this?
  At some point, we need to start removing things, surely. Larry just
  has a higher tolerance for pain :-)
  
  RHEL 6 is shipping GCC 4.4.  True, there are software collections to
  overcome that, but I think supporting GCC 4.4 is a good idea for at
  least a couple more years.
  
  Laszlo, do you still use RHEL 6?  Are you building with GCC 4.4?
  
  My laptop dual-boots RHEL-6 and RHEL-7, but I only use RHEL-6 when I
  need to work on RHEL-6 qemu-kvm or the RHEL-6 kernel. Which is nowadays
  practically never, thankfully.
  
  In addition, I couldn't sensibly *test* OVMF on a RHEL-6 host, because
  the RHEL-6 components lack support for the pflash-backed varstore.
  Which, for me at least, makes *building* OVMF on RHEL-6 kinda moot too.
  
  I have a number of Fedora virtual machines just for build-testing with
  gcc-4.4..gcc-4.9, but they are the consequence of the edk2 compiler
  support, not the reason for it. :)
  
  So, I'm in favor of dropping gcc-4.4 support. (In Fedora release terms,
  gcc-4.4 corresponds to fc13.)
 
 OK, so [supposedly] Larry is the only one who objects to deprecating
 toolchains, but since he has not responded to the suggestion, I think
 we should proceed anyway.
 
 I will respin this series, and instead of bringing CYGGCC and ELFGCC
 etc in line, I will propose to move them to tools_def.attic or
 whichever name is preferred by the group.
 
 Jordan suggested to drop UNIXGCC as well, and introduce MINGW instead
 iff we want the MinGW PE/COFF GCC, and I think we do, if only so that
 we have a LLP64 environment for X64 available to those without the
 possibility or the desire to run a MS toolchains under Windows.

People should be able to build a known-good crossbuild toolchain. This is the 
simplest way to provide that option.

By the way, do you think I can get you to update the mingw-gcc-build.py script 
while you're at it? :)

-Bill

 
 GCC44 could perhaps be moved to the attic as well, but it does not
 need to be in this series imo

-- 
=
-Bill Paul(510) 749-2329 | Senior Member of Technical Staff,
 wp...@windriver.com | Master of Unix-Fu - Wind River Systems
=
   I put a dollar in a change machine. Nothing changed. - George Carlin
=
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 00/16] unify GCC command line options

[Ard Biesheuvel]

On 19 August 2015 at 09:53, Ard Biesheuvel ard.biesheu...@linaro.org wrote:
 On 18 August 2015 at 22:29, Ard Biesheuvel ard.biesheu...@linaro.org wrote:
 On 18 August 2015 at 22:03, Ard Biesheuvel ard.biesheu...@linaro.org wrote:
 On 18 August 2015 at 19:35, David Woodhouse dw...@infradead.org wrote:
 On Tue, 2015-08-18 at 17:52 +0200, Ard Biesheuvel wrote:
 On 18 August 2015 at 17:19, Jordan Justen jordan.l.jus...@intel.com 
 wrote:
  Last time I checked, GCC44 ~ GCC49 all produced images roughly in the
  same ball park size-wise. UNIXGCC produced much larger images because
  it could not strip unused functions/data.

 Yeah, that is still true, unfortunately.

 Is it really still true?

 https://sourceware.org/bugzilla/show_bug.cgi?id=11539#c14

 If the patch that Nick committed to fix this *isn't* working, please
 add a comment telling him that :)


 I did a quick test with the gdb-7.10-branch of binutils-gdb, and while
 it does make some difference, it is still not sufficient

 Building OvmfX64 in RELEASE mode gives me

 Before:
   the required fv image size 0xd67c0 exceeds the set fv image size 0xcc000

 After:
   the required fv image size 0xd2a18 exceeds the set fv image size 0xcc000

 where GCC/ELF obviously produces something  0xcc000


 I had mistakenly omitted the -ffunction-sections -fdata-sections
 switches, but adding those makes it even worse

   the required fv image size 0xdbf98 exceeds the set fv image size 0xcc000

 so there is definitely something dodgy going on here.


 I managed to make this work by also adding the
 -fno-asynchronous-unwind-tables option. It appears that
 (unsurprisingly) the unwinding info is preventing code from being
 pruned.

 So with  -Os -ffunction-sections -fdata-sections
 -fno-asynchronous-unwind-tables, we get even better results than
 GCC49, since we can actually turn on size optimization for MinGW.
 On GCC49, we can only enable optimization if we also enable
 -maccumulate-outgoing-args, which -according to the man page- results
 in a notable increase in code size. (I assume this is the reason we
 don't optimize the GCC49 X64 builds at all)

 If I just look at VolInfo of the FVMAIN_COMPACT.Fv generated by each
 build (UNIXGCC with mingw 4.9 vs GCC49), I get 767 KB for MinGW for
 the file length of the first embedded FV, where GCC49 takes up 794 KB.
 Maybe not spectacular, but more than significant.

As it turns out, the -mcmodel=large we use for GCC4x/X64 is causing
much of the bloat here. If I remove it, the GCC49 build shrinks to 751
KB (Again, the size of the first FV. Note that this is compressed
size, but it is relevant nonetheless)

Does anyone remember why we use that? My build runs fine without it
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 00/16] unify GCC command line options

[Ard Biesheuvel]

On 18 August 2015 at 22:29, Ard Biesheuvel ard.biesheu...@linaro.org wrote:
 On 18 August 2015 at 22:03, Ard Biesheuvel ard.biesheu...@linaro.org wrote:
 On 18 August 2015 at 19:35, David Woodhouse dw...@infradead.org wrote:
 On Tue, 2015-08-18 at 17:52 +0200, Ard Biesheuvel wrote:
 On 18 August 2015 at 17:19, Jordan Justen jordan.l.jus...@intel.com 
 wrote:
  Last time I checked, GCC44 ~ GCC49 all produced images roughly in the
  same ball park size-wise. UNIXGCC produced much larger images because
  it could not strip unused functions/data.

 Yeah, that is still true, unfortunately.

 Is it really still true?

 https://sourceware.org/bugzilla/show_bug.cgi?id=11539#c14

 If the patch that Nick committed to fix this *isn't* working, please
 add a comment telling him that :)


 I did a quick test with the gdb-7.10-branch of binutils-gdb, and while
 it does make some difference, it is still not sufficient

 Building OvmfX64 in RELEASE mode gives me

 Before:
   the required fv image size 0xd67c0 exceeds the set fv image size 0xcc000

 After:
   the required fv image size 0xd2a18 exceeds the set fv image size 0xcc000

 where GCC/ELF obviously produces something  0xcc000


 I had mistakenly omitted the -ffunction-sections -fdata-sections
 switches, but adding those makes it even worse

   the required fv image size 0xdbf98 exceeds the set fv image size 0xcc000

 so there is definitely something dodgy going on here.


I managed to make this work by also adding the
-fno-asynchronous-unwind-tables option. It appears that
(unsurprisingly) the unwinding info is preventing code from being
pruned.

So with  -Os -ffunction-sections -fdata-sections
-fno-asynchronous-unwind-tables, we get even better results than
GCC49, since we can actually turn on size optimization for MinGW.
On GCC49, we can only enable optimization if we also enable
-maccumulate-outgoing-args, which -according to the man page- results
in a notable increase in code size. (I assume this is the reason we
don't optimize the GCC49 X64 builds at all)

If I just look at VolInfo of the FVMAIN_COMPACT.Fv generated by each
build (UNIXGCC with mingw 4.9 vs GCC49), I get 767 KB for MinGW for
the file length of the first embedded FV, where GCC49 takes up 794 KB.
Maybe not spectacular, but more than significant.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 00/16] unify GCC command line options

[Ard Biesheuvel]

On 17 August 2015 at 21:16, David Woodhouse dw...@infradead.org wrote:
 See http://www.infradead.org/rpr.html
 X-SRS-Rewrite: SMTP reverse-path rewritten from dw...@infradead.org by 
 twosheds.infradead.org
 See http://www.infradead.org/rpr.html


 On 2015-08-17 11:25:41, David Woodhouse wrote:
 On Mon, 2015-08-17 at 11:22 -0700, Jordan Justen wrote:
  Can't you use an elf-based GCC4.9 with the GCC49 toolchain instead?

 Not for testing LLP64, no.

 How/who is this helping?

 It was massively useful for testing the OpenSSL stuff I've been working on
 recently. It showed up a number of issues which would otherwise only occur
 a Windows build.


Indeed. I don't use Windows or have access to any MS toolchains, so
this is basically the only way to make sure my code is LLP64 clean.

  I'm not sure it makes sense to 'upgrade' the UNIXGCC toolchain to be
  based on GCC 4.9 rather than 4.3. I think GCC 4.3 was implicitly part
  of the definition of the UNIXGCC toolchain. (Well, maybe explicitly if
  you count the comment in tools_def :) This is why I'd rather deprecate
  it as a toolchain, and use the GCC4X toolchains instead.

 Or kill UNIXGCC and replace it with MINGWGCC so the historical baggage
 is lost.

 Maybe MINGW49. But, please not before we figure out how to actually
 deprecate toolchains. :)


Why *must* we have the version encoded into the name? For GCC4x, the
differences are so minor that it is just maintenance overhead imo. I
used CLANG35 instead of CLANG per your request, but I am definitely
not going to add CLANG36 CLANG37 etc unless there is a real need.

 By 'figure out', I mean get to the point where we are okay with
 actually deprecating toolchains.

 Deprecating toolchains is pointless until we can ditch the badly
 maintained 20th century crap that holds us back from using C99 code. Once
 we have the political will to say here's a nickel, kid. Buy yourself a
 real compiler and provide Windows-hosted GCC or LLVM based toolchains,
 there really is no point.


Well, I would think that deprecating toolchains that don't support C99
is the first step towards allowing C99.

We are kidding ourselves if we think that 'present in
tools_def.template' and 'supported' are the same thing. In other
words, many of these toolchains are already deprecated since nobody
uses them, and they may not work anymore at all.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 00/16] unify GCC command line options

[Ard Biesheuvel]

On 17 August 2015 at 20:53, Jordan Justen jordan.l.jus...@intel.com wrote:
 On 2015-08-17 11:25:56, Ard Biesheuvel wrote:
 On 17 August 2015 at 20:22, Jordan Justen jordan.l.jus...@intel.com wrote:
  Can't you use an elf-based GCC4.9 with the GCC49 toolchain instead?
 
  I'm not sure it makes sense to 'upgrade' the UNIXGCC toolchain to be
  based on GCC 4.9 rather than 4.3. I think GCC 4.3 was implicitly part
  of the definition of the UNIXGCC toolchain. (Well, maybe explicitly if
  you count the comment in tools_def :) This is why I'd rather deprecate
  it as a toolchain, and use the GCC4X toolchains instead.
 

 No, you can't really.

 MinGW generates PE/COFF not ELF, so much of the linker command line is
 different, and it really deserves a toolchain of its own

 Why does it deserve a toolchain of its own if the other toolchain
 produces better code? Why should EDK II care about using the different
 linker path if it isn't the best recommended way to build images?


By the same logic, why on earth do we insist on retaining support for
GCC44 and GCC45?

Note that it is not about the linker path, but about the options that
we pass, for instance to get 4 KB section alignment. MinGW does not
need a linker script for this, you can simply set --section-alignment
and --file-alignment on the command line.

As for the PE/COFF support: if you are incorporating PE/COFF binary
static libraries into your build, you need a native PE/COFF toolchain.
But in general, I think the ELF to PE/COFF conversion is not the most
elegant step in the build, and I would prefer to avoid it if possible
(only, there is no PE/COFF support in the GNU tools for ARM or
AARCH64)

 Making version 4.3.0 part of the definition of UNIXGCC sounds awkward
 to me. In fact, the idea of supporting all toolchains into eternity
 sounds awkward, and it is obviously not working, since many are
 deprecated and don't work at all or only partially. It would be much
 better imo to allow a definition like UNIXGCC to evolve with the state
 of the art

 I mostly agree, but I would rather see us add new toolchains and
 deprecate the old ones rather than evolving the requirements for a
 particular toolchain.

 I think the name UNIXGCC is too generic and too short sighted. It made
 sense at the time, but I don't think we should keep moving it forward
 and turn it into a moving target.

 The MYTOOLS toolchain was what you are describing, but for MSVC. It
 looks like it is stuck at VS2008 though. Anyway, I guess we should
 also deprecate MYTOOLS. :)


Probably, yes.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 00/16] unify GCC command line options

[Bruce Cran]

On 8/18/2015 10:26 AM, Ard Biesheuvel wrote:

Ultimately, it would be useful to have a subset of
platforms/toolchains that need to pass before a patch is accepted, but
I am aware that we are still far away from anything like that.

For internal use, I have set up some infrastructure that we can use to
test patch series against the following combos

...
(https://ci.linaro.org/job/leg-tianocore-edk2-build-test/)

It would be good if we could formalize something like this in the
future, i.e., define a 'gold standard' of combos that need to build
correctly, and automate it. (I know having MSFT toolchains in here
would be better, but they are not accessible to everyone as easily.)
In the mean time, triggering these jobs by hand when proposing series
that touch common code should help gain confidence that it won't break
the build for someone else.


In case anyone's wondering - I *did* have a Jenkins server setup that 
did something similar, but it was going to cost over $500/month to run 
all the various platforms on AWS so I shut it down for now.


--
Bruce
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 00/16] unify GCC command line options

[Laszlo Ersek]

On 08/18/15 22:04, Paolo Bonzini wrote:
 
 
 On 18/08/2015 08:52, Ard Biesheuvel wrote:
 Personally, I would not mind deprecating GCC44, but the biggest
 question I would have is what toolchains do the latest UDK releases
 claim to support.

 We also have the issue that every time I ask about deprecating a
 toolchain, Larry looks at me like I'm crazy. :)

 Well, perhaps he can chime in and explain his motivation behind this?
 At some point, we need to start removing things, surely. Larry just
 has a higher tolerance for pain :-)
 
 RHEL 6 is shipping GCC 4.4.  True, there are software collections to
 overcome that, but I think supporting GCC 4.4 is a good idea for at
 least a couple more years.
 
 Laszlo, do you still use RHEL 6?  Are you building with GCC 4.4?

My laptop dual-boots RHEL-6 and RHEL-7, but I only use RHEL-6 when I
need to work on RHEL-6 qemu-kvm or the RHEL-6 kernel. Which is nowadays
practically never, thankfully.

In addition, I couldn't sensibly *test* OVMF on a RHEL-6 host, because
the RHEL-6 components lack support for the pflash-backed varstore.
Which, for me at least, makes *building* OVMF on RHEL-6 kinda moot too.

I have a number of Fedora virtual machines just for build-testing with
gcc-4.4..gcc-4.9, but they are the consequence of the edk2 compiler
support, not the reason for it. :)

So, I'm in favor of dropping gcc-4.4 support. (In Fedora release terms,
gcc-4.4 corresponds to fc13.)

Thanks!
Laszlo

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 00/16] unify GCC command line options

[Paolo Bonzini]

On 18/08/2015 08:52, Ard Biesheuvel wrote:
  Personally, I would not mind deprecating GCC44, but the biggest
  question I would have is what toolchains do the latest UDK releases
  claim to support.
 
  We also have the issue that every time I ask about deprecating a
  toolchain, Larry looks at me like I'm crazy. :)

 Well, perhaps he can chime in and explain his motivation behind this?
 At some point, we need to start removing things, surely. Larry just
 has a higher tolerance for pain :-)

RHEL 6 is shipping GCC 4.4.  True, there are software collections to
overcome that, but I think supporting GCC 4.4 is a good idea for at
least a couple more years.

Laszlo, do you still use RHEL 6?  Are you building with GCC 4.4?

Paolo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 00/16] unify GCC command line options

[Ard Biesheuvel]

On 18 August 2015 at 22:03, Ard Biesheuvel ard.biesheu...@linaro.org wrote:
 On 18 August 2015 at 19:35, David Woodhouse dw...@infradead.org wrote:
 On Tue, 2015-08-18 at 17:52 +0200, Ard Biesheuvel wrote:
 On 18 August 2015 at 17:19, Jordan Justen jordan.l.jus...@intel.com wrote:
  Last time I checked, GCC44 ~ GCC49 all produced images roughly in the
  same ball park size-wise. UNIXGCC produced much larger images because
  it could not strip unused functions/data.

 Yeah, that is still true, unfortunately.

 Is it really still true?

 https://sourceware.org/bugzilla/show_bug.cgi?id=11539#c14

 If the patch that Nick committed to fix this *isn't* working, please
 add a comment telling him that :)


 I did a quick test with the gdb-7.10-branch of binutils-gdb, and while
 it does make some difference, it is still not sufficient

 Building OvmfX64 in RELEASE mode gives me

 Before:
   the required fv image size 0xd67c0 exceeds the set fv image size 0xcc000

 After:
   the required fv image size 0xd2a18 exceeds the set fv image size 0xcc000

 where GCC/ELF obviously produces something  0xcc000


I had mistakenly omitted the -ffunction-sections -fdata-sections
switches, but adding those makes it even worse

  the required fv image size 0xdbf98 exceeds the set fv image size 0xcc000

so there is definitely something dodgy going on here.

I may not have the bandwidth to investigate this in depth, though.

-- 
Ard.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 00/16] unify GCC command line options

[Ard Biesheuvel]

On 18 August 2015 at 17:19, Jordan Justen jordan.l.jus...@intel.com wrote:
 On 2015-08-18 03:57:51, Ard Biesheuvel wrote:
 On 17 August 2015 at 20:53, Jordan Justen jordan.l.jus...@intel.com wrote:
  On 2015-08-17 11:25:56, Ard Biesheuvel wrote:
  MinGW generates PE/COFF not ELF, so much of the linker command line is
  different, and it really deserves a toolchain of its own
 
  Why does it deserve a toolchain of its own if the other toolchain
  produces better code? Why should EDK II care about using the different
  linker path if it isn't the best recommended way to build images?
 

 By the same logic, why on earth do we insist on retaining support for
 GCC44 and GCC45?

 Last time I checked, GCC44 ~ GCC49 all produced images roughly in the
 same ball park size-wise. UNIXGCC produced much larger images because
 it could not strip unused functions/data.


Yeah, that is still true, unfortunately. Having a LLP64 toolchain
under Linux is nice, though, if only for test coverage

 Personally, I would not mind deprecating GCC44, but the biggest
 question I would have is what toolchains do the latest UDK releases
 claim to support.

 We also have the issue that every time I ask about deprecating a
 toolchain, Larry looks at me like I'm crazy. :)


Well, perhaps he can chime in and explain his motivation behind this?
At some point, we need to start removing things, surely. Larry just
has a higher tolerance for pain :-)

 Note that it is not about the linker path, but about the options that
 we pass, for instance to get 4 KB section alignment. MinGW does not
 need a linker script for this, you can simply set --section-alignment
 and --file-alignment on the command line.

 As for the PE/COFF support: if you are incorporating PE/COFF binary
 static libraries into your build, you need a native PE/COFF toolchain.

 Is this something we want to support?


Perhaps not

 But in general, I think the ELF to PE/COFF conversion is not the most
 elegant step in the build, and I would prefer to avoid it if possible
 (only, there is no PE/COFF support in the GNU tools for ARM or
 AARCH64)

 It is doing a better job than any other GCC based option we have.

 Certainly LTO will be a big change for our GCC based builds. If
 somehow LTO support is finally integrated into EDK II and manages to
 directly produce a PE/COFF image easily on Linux, then I don't think
 ELF is needed.


Yes, that is another thing to consider.

All in all, I think we agree that it would be useful to get rid of as
much cruft as we can, and my cleanup is intended to reduce the
maintenance burden of the GCC4x series that we want to keep. I am
perfectly happy getting rid of ELFGCC, CYGGCC and even UNIXGCC if we
can come up with a reasonble replacement.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 00/16] unify GCC command line options

[Jordan Justen]

On 2015-08-18 03:57:51, Ard Biesheuvel wrote:
 On 17 August 2015 at 20:53, Jordan Justen jordan.l.jus...@intel.com wrote:
  On 2015-08-17 11:25:56, Ard Biesheuvel wrote:
  MinGW generates PE/COFF not ELF, so much of the linker command line is
  different, and it really deserves a toolchain of its own
 
  Why does it deserve a toolchain of its own if the other toolchain
  produces better code? Why should EDK II care about using the different
  linker path if it isn't the best recommended way to build images?
 
 
 By the same logic, why on earth do we insist on retaining support for
 GCC44 and GCC45?

Last time I checked, GCC44 ~ GCC49 all produced images roughly in the
same ball park size-wise. UNIXGCC produced much larger images because
it could not strip unused functions/data.

Personally, I would not mind deprecating GCC44, but the biggest
question I would have is what toolchains do the latest UDK releases
claim to support.

We also have the issue that every time I ask about deprecating a
toolchain, Larry looks at me like I'm crazy. :)

 Note that it is not about the linker path, but about the options that
 we pass, for instance to get 4 KB section alignment. MinGW does not
 need a linker script for this, you can simply set --section-alignment
 and --file-alignment on the command line.
 
 As for the PE/COFF support: if you are incorporating PE/COFF binary
 static libraries into your build, you need a native PE/COFF toolchain.

Is this something we want to support?

 But in general, I think the ELF to PE/COFF conversion is not the most
 elegant step in the build, and I would prefer to avoid it if possible
 (only, there is no PE/COFF support in the GNU tools for ARM or
 AARCH64)

It is doing a better job than any other GCC based option we have.

Certainly LTO will be a big change for our GCC based builds. If
somehow LTO support is finally integrated into EDK II and manages to
directly produce a PE/COFF image easily on Linux, then I don't think
ELF is needed.

-Jordan
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v2 00/16] unify GCC command line options

[Ard Biesheuvel]

This got a bit out of hand after I noticed the ELFGCC and UNIXGCC
toolchains that needed some tlc as well.

Anyway, this series aims to refactor the toolchains definitions for
UNIXGCC, GCC44, GCC45, GCC46, GCC47, GCC48, GCC49, CLANG35, ELFGCC,
CYGGCC and CYGGCCxASL so that they share as much of the settings as
possible. Currently, there is very little coordination between these,
which means for instance that the 4 KB alignment feature is only supported
on GCC4x at the moment.

The primary difference between these toolchains is that GCC4x and ELFGCC
are entirely ELF based, whereas the other are PE/COFF based (but only when
building for IA32 or X64)

Note that this series does not remove any toolchains, nor should it result
in major changes in the command lines that are passed to the various tools.
However, things may be reordered, and (in case of ELFGCC), missing functionality
such as increased section alignment has been added so there are some changes
there.

Patch #1 is a patch from Scott that I am reposting, but updated to cover
AARCH64 as well.

Patch #2 fixes a problem in the GenFv tool where it may access unallocated
memory while rebasing the FFS when using large section and file alignment.

Patch #3 removes an unused DEFINE from tools_def

Patch #4 moved some warning flags that were applied to GCC4x 4.6 and up to
all GCC versions.

Patch #5 is the first big refactor patch that introduces PE and ELF variants
for some CC flags.

Patch #6 unifies the IA32 and X64 CC flags for all toolchains listed above.

Patch #7 fixes the issue mentioned by Bill where the underscore decoration
is erroneously applied on X64 as well.

Patch #8 is the second refactor the introduces PE and ELF variants for the
various DLINK flags.

Patch #9 changes the way the start of the .data section is set in GccBase.lds.
This is needed since the linker will reorganize the internal layout of the .data
section rather than update its start address to ensure all objects that it
contains meet their respective alignments, even if the start address is not
aligned to the max value of all inputs.

Patch #10 removes the explicit 64 byte alignment applied to GCC 4.9. The latest
GenFw and linker script propagate the alignment automatically, i.e., if objects
with such alignment requirement are present, GCC will set the ELF header
accordingly, and this value will be used for the PE/COFF section alignment
as well.

Patch #11 unifies the IA32 and X64 linker flags for all toolchains listed above.

Patch #12 unifies the ARM and AARCH64 CC flags, i.e., it removes all the
redundant definitions.

Patch #13 as #11 but for the linker.

Patch #14 unifies the ASM flags for all archs.

Patch #15 brings the remaining configuration options of ELFGCC in line with
the GCC4x series.

Patch #16 is a PoC that allows Ovmf/X64 to be built with 4 KB section alignment
for DXE_RUNTIME modules using UNIXGCC and ELFGCC, as is required to support
the properties table memprotection feature.

Changes since v1:
- added patch #9 to address the IA32 and X86 failures on 4.9 reported by Scott
- don't pass -mno-unaligned-access to ARM 4.6 compiler (Scott)
- improved wording of commit messages of various patches
- rebased onto latest upstream, which includes a fix related to the ARM 4.6
  issue mentioned above

Branch can be found here
https://git.linaro.org/people/ard.biesheuvel/uefi-next.git/shortlog/refs/heads/unify-gcc-v2

Ard Biesheuvel (15):
  BaseTools/GenFv: use PE/COFF virtual section size if raw size is
larger
  BaseTools GCC: remove unused definition of GCC_WINDRES_FLAGS
  BaseTools GCC: merge warning flags for all GCC versions
  BaseTools GCC: refactor tools_def internal GCC defines for CC flags
  BaseTools GCC: unify all IA32 and X64 CC flags for ELF based GCC
  BaseTools GCC: use leading underscore for symbol names where
appropriate
  BaseTools GCC: refactor tools_def internal GCC defines for [AS]DLINK
  BaseTools GCC: don't set .data address explicitly
  BaseTools GCC: remove GCC 4.9 specific linker alignment override
  BaseTools GCC: unify all IA32 and X64 [AS]DLINK[2] flags for ELF based
GCC
  BaseTools GCC: unify ARM and AARCH64 GCC compiler flags
  BaseTools GCC: unify ARM and AARCH64 DLINK flags for all GCC versions
  BaseTools GCC: unify ASM flags for all GCC versions
  BaseTools GCC: align ELFGCC with GCC4x toolchains
  OvmfPkg/X64: enable 4 KB alignment for DXE_RUNTIME modules

Scott Duplichan (1):
  BaseTools GCC: Fix GCC49 build failure

 BaseTools/Conf/tools_def.template   | 412 
 BaseTools/Scripts/GccBase.lds   |   3 +-
 BaseTools/Source/C/GenFv/GenFvInternalLib.c |   2 +-
 OvmfPkg/OvmfPkgX64.dsc  |   7 +
 4 files changed, 183 insertions(+), 241 deletions(-)

-- 
1.9.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 00/16] unify GCC command line options

[Ard Biesheuvel]

On 17 August 2015 at 19:53, Jordan Justen jordan.l.jus...@intel.com wrote:
 On 2015-08-17 07:24:57, Ard Biesheuvel wrote:
 This got a bit out of hand after I noticed the ELFGCC and UNIXGCC
 toolchains that needed some tlc as well.

 Anyway, this series aims to refactor the toolchains definitions for
 UNIXGCC, GCC44, GCC45, GCC46, GCC47, GCC48, GCC49, CLANG35, ELFGCC,
 CYGGCC and CYGGCCxASL so that they share as much of the settings as

 UNIXGCC and CYGGCC are GCC 4.3  mingw based. Did this get tested?


I sent some patches around to bring them up to date:

http://thread.gmane.org/gmane.comp.bios.edk2.devel/1297

and with that version, it works fine. GCC 4.3 probably does not work
anymore for X64, since it incorrectly decorates symbol names with
underscores, which the MS ABI only specifies for 32-bit code.

 I think ELFGCC is unused at this point. (And has been since UnixPkg
 was deprecated.)

 I think we should deprecate all three of these toolchains. I would
 like to see us move them to BaseTools/Conf/tools_def.deprecated. I'll
 add Larry to this email, because I think he disagrees with deprecating
 toolchains...


I agree. It makes no sense to have dozens of toolchains when only a
couple are widely used by developers, especially with new features
like the 4 KB alignment for memory permissions that rely on options
that are only passed to some of them.

I already removed ARMGCC and ARMLINUXGCC last week, by the way, but I
don't suppose Larry would care about those?

 If you make these changes and it breaks those toolchains, I don't
 think we would be able to notice, because I don't think we test them
 in our build pool anymore. To me this is all the more reason to move
 them out of tools_def.template.


The only ones I did not test are the CYGGCC ones, which I cannot test
since it obviously only runs under Windows. Everything else seems to
work just fine, including mingw and IPF/ELF, although more coverage is
required of course.

-- 
Ard.


 possible. Currently, there is very little coordination between these,
 which means for instance that the 4 KB alignment feature is only supported
 on GCC4x at the moment.

 The primary difference between these toolchains is that GCC4x and ELFGCC
 are entirely ELF based, whereas the other are PE/COFF based (but only when
 building for IA32 or X64)

 Note that this series does not remove any toolchains, nor should it result
 in major changes in the command lines that are passed to the various tools.
 However, things may be reordered, and (in case of ELFGCC), missing 
 functionality
 such as increased section alignment has been added so there are some changes
 there.

 Patch #1 is a patch from Scott that I am reposting, but updated to cover
 AARCH64 as well.

 Patch #2 fixes a problem in the GenFv tool where it may access unallocated
 memory while rebasing the FFS when using large section and file alignment.

 Patch #3 removes an unused DEFINE from tools_def

 Patch #4 moved some warning flags that were applied to GCC4x 4.6 and up to
 all GCC versions.

 Patch #5 is the first big refactor patch that introduces PE and ELF variants
 for some CC flags.

 Patch #6 unifies the IA32 and X64 CC flags for all toolchains listed above.

 Patch #7 fixes the issue mentioned by Bill where the underscore decoration
 is erroneously applied on X64 as well.

 Patch #8 is the second refactor the introduces PE and ELF variants for the
 various DLINK flags.

 Patch #9 changes the way the start of the .data section is set in 
 GccBase.lds.
 This is needed since the linker will reorganize the internal layout of the 
 .data
 section rather than update its start address to ensure all objects that it
 contains meet their respective alignments, even if the start address is not
 aligned to the max value of all inputs.

 Patch #10 removes the explicit 64 byte alignment applied to GCC 4.9. The 
 latest
 GenFw and linker script propagate the alignment automatically, i.e., if 
 objects
 with such alignment requirement are present, GCC will set the ELF header
 accordingly, and this value will be used for the PE/COFF section alignment
 as well.

 Patch #11 unifies the IA32 and X64 linker flags for all toolchains listed 
 above.

 Patch #12 unifies the ARM and AARCH64 CC flags, i.e., it removes all the
 redundant definitions.

 Patch #13 as #11 but for the linker.

 Patch #14 unifies the ASM flags for all archs.

 Patch #15 brings the remaining configuration options of ELFGCC in line with
 the GCC4x series.

 Patch #16 is a PoC that allows Ovmf/X64 to be built with 4 KB section 
 alignment
 for DXE_RUNTIME modules using UNIXGCC and ELFGCC, as is required to support
 the properties table memprotection feature.

 Changes since v1:
 - added patch #9 to address the IA32 and X86 failures on 4.9 reported by 
 Scott
 - don't pass -mno-unaligned-access to ARM 4.6 compiler (Scott)
 - improved wording of commit messages of various patches
 - rebased onto latest upstream, which includes a fix related to the ARM 4.6

Re: [edk2] [PATCH v2 00/16] unify GCC command line options

[Jordan Justen]

On 2015-08-17 07:24:57, Ard Biesheuvel wrote:
 This got a bit out of hand after I noticed the ELFGCC and UNIXGCC
 toolchains that needed some tlc as well.
 
 Anyway, this series aims to refactor the toolchains definitions for
 UNIXGCC, GCC44, GCC45, GCC46, GCC47, GCC48, GCC49, CLANG35, ELFGCC,
 CYGGCC and CYGGCCxASL so that they share as much of the settings as

UNIXGCC and CYGGCC are GCC 4.3  mingw based. Did this get tested?

I think ELFGCC is unused at this point. (And has been since UnixPkg
was deprecated.)

I think we should deprecate all three of these toolchains. I would
like to see us move them to BaseTools/Conf/tools_def.deprecated. I'll
add Larry to this email, because I think he disagrees with deprecating
toolchains...

If you make these changes and it breaks those toolchains, I don't
think we would be able to notice, because I don't think we test them
in our build pool anymore. To me this is all the more reason to move
them out of tools_def.template.

-Jordan

 possible. Currently, there is very little coordination between these,
 which means for instance that the 4 KB alignment feature is only supported
 on GCC4x at the moment.
 
 The primary difference between these toolchains is that GCC4x and ELFGCC
 are entirely ELF based, whereas the other are PE/COFF based (but only when
 building for IA32 or X64)
 
 Note that this series does not remove any toolchains, nor should it result
 in major changes in the command lines that are passed to the various tools.
 However, things may be reordered, and (in case of ELFGCC), missing 
 functionality
 such as increased section alignment has been added so there are some changes
 there.
 
 Patch #1 is a patch from Scott that I am reposting, but updated to cover
 AARCH64 as well.
 
 Patch #2 fixes a problem in the GenFv tool where it may access unallocated
 memory while rebasing the FFS when using large section and file alignment.
 
 Patch #3 removes an unused DEFINE from tools_def
 
 Patch #4 moved some warning flags that were applied to GCC4x 4.6 and up to
 all GCC versions.
 
 Patch #5 is the first big refactor patch that introduces PE and ELF variants
 for some CC flags.
 
 Patch #6 unifies the IA32 and X64 CC flags for all toolchains listed above.
 
 Patch #7 fixes the issue mentioned by Bill where the underscore decoration
 is erroneously applied on X64 as well.
 
 Patch #8 is the second refactor the introduces PE and ELF variants for the
 various DLINK flags.
 
 Patch #9 changes the way the start of the .data section is set in GccBase.lds.
 This is needed since the linker will reorganize the internal layout of the 
 .data
 section rather than update its start address to ensure all objects that it
 contains meet their respective alignments, even if the start address is not
 aligned to the max value of all inputs.
 
 Patch #10 removes the explicit 64 byte alignment applied to GCC 4.9. The 
 latest
 GenFw and linker script propagate the alignment automatically, i.e., if 
 objects
 with such alignment requirement are present, GCC will set the ELF header
 accordingly, and this value will be used for the PE/COFF section alignment
 as well.
 
 Patch #11 unifies the IA32 and X64 linker flags for all toolchains listed 
 above.
 
 Patch #12 unifies the ARM and AARCH64 CC flags, i.e., it removes all the
 redundant definitions.
 
 Patch #13 as #11 but for the linker.
 
 Patch #14 unifies the ASM flags for all archs.
 
 Patch #15 brings the remaining configuration options of ELFGCC in line with
 the GCC4x series.
 
 Patch #16 is a PoC that allows Ovmf/X64 to be built with 4 KB section 
 alignment
 for DXE_RUNTIME modules using UNIXGCC and ELFGCC, as is required to support
 the properties table memprotection feature.
 
 Changes since v1:
 - added patch #9 to address the IA32 and X86 failures on 4.9 reported by Scott
 - don't pass -mno-unaligned-access to ARM 4.6 compiler (Scott)
 - improved wording of commit messages of various patches
 - rebased onto latest upstream, which includes a fix related to the ARM 4.6
   issue mentioned above
 
 Branch can be found here
 https://git.linaro.org/people/ard.biesheuvel/uefi-next.git/shortlog/refs/heads/unify-gcc-v2
 
 Ard Biesheuvel (15):
   BaseTools/GenFv: use PE/COFF virtual section size if raw size is
 larger
   BaseTools GCC: remove unused definition of GCC_WINDRES_FLAGS
   BaseTools GCC: merge warning flags for all GCC versions
   BaseTools GCC: refactor tools_def internal GCC defines for CC flags
   BaseTools GCC: unify all IA32 and X64 CC flags for ELF based GCC
   BaseTools GCC: use leading underscore for symbol names where
 appropriate
   BaseTools GCC: refactor tools_def internal GCC defines for [AS]DLINK
   BaseTools GCC: don't set .data address explicitly
   BaseTools GCC: remove GCC 4.9 specific linker alignment override
   BaseTools GCC: unify all IA32 and X64 [AS]DLINK[2] flags for ELF based
 GCC
   BaseTools GCC: unify ARM and AARCH64 GCC compiler flags
   BaseTools GCC: unify ARM and AARCH64 

Re: [edk2] [PATCH v2 00/16] unify GCC command line options

[David Woodhouse]

On Mon, 2015-08-17 at 10:53 -0700, Jordan Justen wrote:
 
 UNIXGCC and CYGGCC are GCC 4.3  mingw based. Did this get tested?
 
 I think ELFGCC is unused at this point. (And has been since UnixPkg
 was deprecated.)
 
 I think we should deprecate all three of these toolchains. I would
 like to see us move them to BaseTools/Conf/tools_def.deprecated. I'll
 add Larry to this email, because I think he disagrees with 
 deprecating
 toolchains...
 
 If you make these changes and it breaks those toolchains, I don't
 think we would be able to notice, because I don't think we test them
 in our build pool anymore. To me this is all the more reason to move
 them out of tools_def.template.

I was building with UNIXGCC last week, to test LLP64 builds without the
pain of actually having to deal with Windows.

I'd rather see it updated to work with modern MinGW rather than
deprecated.

-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation


smime.p7s
Description: S/MIME cryptographic signature
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 00/16] unify GCC command line options

[Bill Paul]

Of all the gin joints in all the towns in all the world, David Woodhouse had 
to walk into mine at 11:00:23 on Monday 17 August 2015 and say:

 On Mon, 2015-08-17 at 10:53 -0700, Jordan Justen wrote:
  UNIXGCC and CYGGCC are GCC 4.3  mingw based. Did this get tested?
  
  I think ELFGCC is unused at this point. (And has been since UnixPkg
  was deprecated.)
  
  I think we should deprecate all three of these toolchains. I would
  like to see us move them to BaseTools/Conf/tools_def.deprecated. I'll
  add Larry to this email, because I think he disagrees with
  deprecating
  toolchains...
  
  If you make these changes and it breaks those toolchains, I don't
  think we would be able to notice, because I don't think we test them
  in our build pool anymore. To me this is all the more reason to move
  them out of tools_def.template.
 
 I was building with UNIXGCC last week, to test LLP64 builds without the
 pain of actually having to deal with Windows.
 
 I'd rather see it updated to work with modern MinGW rather than
 deprecated.

I use UNIXGCC with the cross-compiler toolchain generated by mingw-gcc-
build.py. Yes, I know the existing version of the script uses GCC 4.3.0. 
That's why I made an updated version that uses 4.9.3:

http://people.freebsd.org/~wpaul/edk2/mingw-gcc-build.py

I know you don't want to support this script, that's why I did the work for 
you. :) Yes I've tested both IA32 and X64 builds. Yes they work fine.

There is value in being able to bootstrap your own cross-build toolchain on 
whatever platform. I don't think you should be so quick to remove it.

-Bill

-- 
=
-Bill Paul(510) 749-2329 | Senior Member of Technical Staff,
 wp...@windriver.com | Master of Unix-Fu - Wind River Systems
=
   I put a dollar in a change machine. Nothing changed. - George Carlin
=
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 00/16] unify GCC command line options

[Jordan Justen]

On 2015-08-17 11:10:57, Bill Paul wrote:
 Of all the gin joints in all the towns in all the world, David Woodhouse had 
 to walk into mine at 11:00:23 on Monday 17 August 2015 and say:
 
  On Mon, 2015-08-17 at 10:53 -0700, Jordan Justen wrote:
   UNIXGCC and CYGGCC are GCC 4.3  mingw based. Did this get tested?
   
   I think ELFGCC is unused at this point. (And has been since UnixPkg
   was deprecated.)
   
   I think we should deprecate all three of these toolchains. I would
   like to see us move them to BaseTools/Conf/tools_def.deprecated. I'll
   add Larry to this email, because I think he disagrees with
   deprecating
   toolchains...
   
   If you make these changes and it breaks those toolchains, I don't
   think we would be able to notice, because I don't think we test them
   in our build pool anymore. To me this is all the more reason to move
   them out of tools_def.template.
  
  I was building with UNIXGCC last week, to test LLP64 builds without the
  pain of actually having to deal with Windows.
  
  I'd rather see it updated to work with modern MinGW rather than
  deprecated.
 
 I use UNIXGCC with the cross-compiler toolchain generated by mingw-gcc-
 build.py. Yes, I know the existing version of the script uses GCC 4.3.0. 
 That's why I made an updated version that uses 4.9.3:
 
 http://people.freebsd.org/~wpaul/edk2/mingw-gcc-build.py
 
 I know you don't want to support this script, that's why I did the work for 
 you. :) Yes I've tested both IA32 and X64 builds. Yes they work fine.
 
 There is value in being able to bootstrap your own cross-build toolchain on 
 whatever platform. I don't think you should be so quick to remove it.

Can't you use an elf-based GCC4.9 with the GCC49 toolchain instead?

I'm not sure it makes sense to 'upgrade' the UNIXGCC toolchain to be
based on GCC 4.9 rather than 4.3. I think GCC 4.3 was implicitly part
of the definition of the UNIXGCC toolchain. (Well, maybe explicitly if
you count the comment in tools_def :) This is why I'd rather deprecate
it as a toolchain, and use the GCC4X toolchains instead.

-Jordan
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 00/16] unify GCC command line options

[Scott Duplichan]

Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]  wrote:

]Sent: Monday, August 17, 2015 09:25 AM
]To: edk2-de...@ml01.01.org; yingke.d@intel.com
]Cc: wp...@windriver.com; sc...@notabs.org; Ard Biesheuvel 
ard.biesheu...@linaro.org; jordan.l.jus...@intel.com; ]liming@intel.com; 
dw...@infradead.org
]Subject: [edk2] [PATCH v2 00/16] unify GCC command line options
]
]This got a bit out of hand after I noticed the ELFGCC and UNIXGCC
]toolchains that needed some tlc as well.
]
]Anyway, this series aims to refactor the toolchains definitions for
]UNIXGCC, GCC44, GCC45, GCC46, GCC47, GCC48, GCC49, CLANG35, ELFGCC,
]CYGGCC and CYGGCCxASL so that they share as much of the settings as
]possible. Currently, there is very little coordination between these,
]which means for instance that the 4 KB alignment feature is only supported
]on GCC4x at the moment.
]
]The primary difference between these toolchains is that GCC4x and ELFGCC
]are entirely ELF based, whereas the other are PE/COFF based (but only when
]building for IA32 or X64)
]
]Note that this series does not remove any toolchains, nor should it result
]in major changes in the command lines that are passed to the various tools.
]However, things may be reordered, and (in case of ELFGCC), missing 
functionality
]such as increased section alignment has been added so there are some changes
]there.
]
]Patch #1 is a patch from Scott that I am reposting, but updated to cover
]AARCH64 as well.
]
]Patch #2 fixes a problem in the GenFv tool where it may access unallocated
]memory while rebasing the FFS when using large section and file alignment.
]
]Patch #3 removes an unused DEFINE from tools_def
]
]Patch #4 moved some warning flags that were applied to GCC4x 4.6 and up to
]all GCC versions.
]
]Patch #5 is the first big refactor patch that introduces PE and ELF variants
]for some CC flags.
]
]Patch #6 unifies the IA32 and X64 CC flags for all toolchains listed above.
]
]Patch #7 fixes the issue mentioned by Bill where the underscore decoration
]is erroneously applied on X64 as well.
]
]Patch #8 is the second refactor the introduces PE and ELF variants for the
]various DLINK flags.
]
]Patch #9 changes the way the start of the .data section is set in GccBase.lds.
]This is needed since the linker will reorganize the internal layout of the 
.data
]section rather than update its start address to ensure all objects that it
]contains meet their respective alignments, even if the start address is not
]aligned to the max value of all inputs.
]
]Patch #10 removes the explicit 64 byte alignment applied to GCC 4.9. The latest
]GenFw and linker script propagate the alignment automatically, i.e., if objects
]with such alignment requirement are present, GCC will set the ELF header
]accordingly, and this value will be used for the PE/COFF section alignment
]as well.
]
]Patch #11 unifies the IA32 and X64 linker flags for all toolchains listed 
above.
]
]Patch #12 unifies the ARM and AARCH64 CC flags, i.e., it removes all the
]redundant definitions.
]
]Patch #13 as #11 but for the linker.
]
]Patch #14 unifies the ASM flags for all archs.
]
]Patch #15 brings the remaining configuration options of ELFGCC in line with
]the GCC4x series.
]
]Patch #16 is a PoC that allows Ovmf/X64 to be built with 4 KB section alignment
]for DXE_RUNTIME modules using UNIXGCC and ELFGCC, as is required to support
]the properties table memprotection feature.
]
]Changes since v1:
]- added patch #9 to address the IA32 and X86 failures on 4.9 reported by Scott
]- don't pass -mno-unaligned-access to ARM 4.6 compiler (Scott)
]- improved wording of commit messages of various patches
]- rebased onto latest upstream, which includes a fix related to the ARM 4.6
]  issue mentioned above
]
]Branch can be found here
]https://git.linaro.org/people/ard.biesheuvel/uefi-next.git/shortlog/refs/heads/unify-gcc-v2
]
]Ard Biesheuvel (15):
]  BaseTools/GenFv: use PE/COFF virtual section size if raw size is
]larger
]  BaseTools GCC: remove unused definition of GCC_WINDRES_FLAGS
]  BaseTools GCC: merge warning flags for all GCC versions
]  BaseTools GCC: refactor tools_def internal GCC defines for CC flags
]  BaseTools GCC: unify all IA32 and X64 CC flags for ELF based GCC
]  BaseTools GCC: use leading underscore for symbol names where
]appropriate
]  BaseTools GCC: refactor tools_def internal GCC defines for [AS]DLINK
]  BaseTools GCC: don't set .data address explicitly
]  BaseTools GCC: remove GCC 4.9 specific linker alignment override
]  BaseTools GCC: unify all IA32 and X64 [AS]DLINK[2] flags for ELF based
]GCC
]  BaseTools GCC: unify ARM and AARCH64 GCC compiler flags
]  BaseTools GCC: unify ARM and AARCH64 DLINK flags for all GCC versions
]  BaseTools GCC: unify ASM flags for all GCC versions
]  BaseTools GCC: align ELFGCC with GCC4x toolchains
]  OvmfPkg/X64: enable 4 KB alignment for DXE_RUNTIME modules
]
]Scott Duplichan (1):
]  BaseTools GCC: Fix GCC49 build failure
]
] BaseTools/Conf/tools_def.template

Re: [edk2] [PATCH v2 00/16] unify GCC command line options

[Ard Biesheuvel]

On 17 August 2015 at 20:37, Scott Duplichan sc...@notabs.org wrote:
 Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]  wrote:

 ]Sent: Monday, August 17, 2015 09:25 AM
 ]To: edk2-de...@ml01.01.org; yingke.d@intel.com
 ]Cc: wp...@windriver.com; sc...@notabs.org; Ard Biesheuvel 
 ard.biesheu...@linaro.org; jordan.l.jus...@intel.com; 
 ]liming@intel.com; dw...@infradead.org
 ]Subject: [edk2] [PATCH v2 00/16] unify GCC command line options
 ]
 ]This got a bit out of hand after I noticed the ELFGCC and UNIXGCC
 ]toolchains that needed some tlc as well.
 ]
 ]Anyway, this series aims to refactor the toolchains definitions for
 ]UNIXGCC, GCC44, GCC45, GCC46, GCC47, GCC48, GCC49, CLANG35, ELFGCC,
 ]CYGGCC and CYGGCCxASL so that they share as much of the settings as
 ]possible. Currently, there is very little coordination between these,
 ]which means for instance that the 4 KB alignment feature is only supported
 ]on GCC4x at the moment.
 ]
 ]The primary difference between these toolchains is that GCC4x and ELFGCC
 ]are entirely ELF based, whereas the other are PE/COFF based (but only when
 ]building for IA32 or X64)
 ]
 ]Note that this series does not remove any toolchains, nor should it result
 ]in major changes in the command lines that are passed to the various tools.
 ]However, things may be reordered, and (in case of ELFGCC), missing 
 functionality
 ]such as increased section alignment has been added so there are some changes
 ]there.
 ]
 ]Patch #1 is a patch from Scott that I am reposting, but updated to cover
 ]AARCH64 as well.
 ]
 ]Patch #2 fixes a problem in the GenFv tool where it may access unallocated
 ]memory while rebasing the FFS when using large section and file alignment.
 ]
 ]Patch #3 removes an unused DEFINE from tools_def
 ]
 ]Patch #4 moved some warning flags that were applied to GCC4x 4.6 and up to
 ]all GCC versions.
 ]
 ]Patch #5 is the first big refactor patch that introduces PE and ELF variants
 ]for some CC flags.
 ]
 ]Patch #6 unifies the IA32 and X64 CC flags for all toolchains listed above.
 ]
 ]Patch #7 fixes the issue mentioned by Bill where the underscore decoration
 ]is erroneously applied on X64 as well.
 ]
 ]Patch #8 is the second refactor the introduces PE and ELF variants for the
 ]various DLINK flags.
 ]
 ]Patch #9 changes the way the start of the .data section is set in 
 GccBase.lds.
 ]This is needed since the linker will reorganize the internal layout of the 
 .data
 ]section rather than update its start address to ensure all objects that it
 ]contains meet their respective alignments, even if the start address is not
 ]aligned to the max value of all inputs.
 ]
 ]Patch #10 removes the explicit 64 byte alignment applied to GCC 4.9. The 
 latest
 ]GenFw and linker script propagate the alignment automatically, i.e., if 
 objects
 ]with such alignment requirement are present, GCC will set the ELF header
 ]accordingly, and this value will be used for the PE/COFF section alignment
 ]as well.
 ]
 ]Patch #11 unifies the IA32 and X64 linker flags for all toolchains listed 
 above.
 ]
 ]Patch #12 unifies the ARM and AARCH64 CC flags, i.e., it removes all the
 ]redundant definitions.
 ]
 ]Patch #13 as #11 but for the linker.
 ]
 ]Patch #14 unifies the ASM flags for all archs.
 ]
 ]Patch #15 brings the remaining configuration options of ELFGCC in line with
 ]the GCC4x series.
 ]
 ]Patch #16 is a PoC that allows Ovmf/X64 to be built with 4 KB section 
 alignment
 ]for DXE_RUNTIME modules using UNIXGCC and ELFGCC, as is required to support
 ]the properties table memprotection feature.
 ]
 ]Changes since v1:
 ]- added patch #9 to address the IA32 and X86 failures on 4.9 reported by 
 Scott
 ]- don't pass -mno-unaligned-access to ARM 4.6 compiler (Scott)
 ]- improved wording of commit messages of various patches
 ]- rebased onto latest upstream, which includes a fix related to the ARM 4.6
 ]  issue mentioned above
 ]
 ]Branch can be found here
 ]https://git.linaro.org/people/ard.biesheuvel/uefi-next.git/shortlog/refs/heads/unify-gcc-v2
 ]
 ]Ard Biesheuvel (15):
 ]  BaseTools/GenFv: use PE/COFF virtual section size if raw size is
 ]larger
 ]  BaseTools GCC: remove unused definition of GCC_WINDRES_FLAGS
 ]  BaseTools GCC: merge warning flags for all GCC versions
 ]  BaseTools GCC: refactor tools_def internal GCC defines for CC flags
 ]  BaseTools GCC: unify all IA32 and X64 CC flags for ELF based GCC
 ]  BaseTools GCC: use leading underscore for symbol names where
 ]appropriate
 ]  BaseTools GCC: refactor tools_def internal GCC defines for [AS]DLINK
 ]  BaseTools GCC: don't set .data address explicitly
 ]  BaseTools GCC: remove GCC 4.9 specific linker alignment override
 ]  BaseTools GCC: unify all IA32 and X64 [AS]DLINK[2] flags for ELF based
 ]GCC
 ]  BaseTools GCC: unify ARM and AARCH64 GCC compiler flags
 ]  BaseTools GCC: unify ARM and AARCH64 DLINK flags for all GCC versions
 ]  BaseTools GCC: unify ASM flags for all GCC versions
 ]  BaseTools GCC: align ELFGCC

Re: [edk2] [PATCH v2 00/16] unify GCC command line options

[Bill Paul]

Of all the gin joints in all the towns in all the world, Jordan Justen had to 
walk into mine at 11:22:15 on Monday 17 August 2015 and say:

 On 2015-08-17 11:10:57, Bill Paul wrote:
  Of all the gin joints in all the towns in all the world, David Woodhouse
  had
  
  to walk into mine at 11:00:23 on Monday 17 August 2015 and say:
   On Mon, 2015-08-17 at 10:53 -0700, Jordan Justen wrote:
UNIXGCC and CYGGCC are GCC 4.3  mingw based. Did this get tested?

I think ELFGCC is unused at this point. (And has been since UnixPkg
was deprecated.)

I think we should deprecate all three of these toolchains. I would
like to see us move them to BaseTools/Conf/tools_def.deprecated. I'll
add Larry to this email, because I think he disagrees with
deprecating
toolchains...

If you make these changes and it breaks those toolchains, I don't
think we would be able to notice, because I don't think we test them
in our build pool anymore. To me this is all the more reason to move
them out of tools_def.template.
   
   I was building with UNIXGCC last week, to test LLP64 builds without the
   pain of actually having to deal with Windows.
   
   I'd rather see it updated to work with modern MinGW rather than
   deprecated.
  
  I use UNIXGCC with the cross-compiler toolchain generated by mingw-gcc-
  build.py. Yes, I know the existing version of the script uses GCC 4.3.0.
  That's why I made an updated version that uses 4.9.3:
  
  http://people.freebsd.org/~wpaul/edk2/mingw-gcc-build.py
  
  I know you don't want to support this script, that's why I did the work
  for you. :) Yes I've tested both IA32 and X64 builds. Yes they work
  fine.
  
  There is value in being able to bootstrap your own cross-build toolchain
  on whatever platform. I don't think you should be so quick to remove it.
 
 Can't you use an elf-based GCC4.9 with the GCC49 toolchain instead?

I could, but there's not really much point.

UEFI uses PE/COFF as its object format, right? Using an ELF-based GCC means 
that you have to add a extra conversion step during the build process in order 
to go from ELF to PE/COFF. The rationale for doing it that way is: A lot of 
*NIX systems already have ELF-based system compilers installed, we might as 
well use them. I understand the usefulness of this approach.

However, if I'm going to be bootstrapping my own cross-build tools from 
scratch, that rationale no longer applies: if I have the option of selecting a 
target that gets me PE/COFF objects directly, I might as well do that.

 I'm not sure it makes sense to 'upgrade' the UNIXGCC toolchain to be
 based on GCC 4.9 rather than 4.3. I think GCC 4.3 was implicitly part
 of the definition of the UNIXGCC toolchain. (Well, maybe explicitly if
 you count the comment in tools_def :) This is why I'd rather deprecate
 it as a toolchain, and use the GCC4X toolchains instead.

I don't think this reasoning is valid. It doesn't seem fair to say that just 
because the UNIXGCC target was originally set up to use GCC 4.3.0, you can 
never upgrade it to a newer version. Technically, GCC 4.3.0 is buggy if you 
consider that it gets the underscore decoration convention wrong for X64. I 
would argue that it makes sense to fix this, since if the intent was to 
produce a cross-build toolchain that emulates the Microsoft toolchain 
behavior, it's not actually doing that now. It hasn't been left like that 
because people wanted it that way: it was left like that because until now 
nobody cared enough to fix it.

-Bill

 -Jordan
 ___
 edk2-devel mailing list
 edk2-devel@lists.01.org
 https://lists.01.org/mailman/listinfo/edk2-devel

-- 
=
-Bill Paul(510) 749-2329 | Senior Member of Technical Staff,
 wp...@windriver.com | Master of Unix-Fu - Wind River Systems
=
   I put a dollar in a change machine. Nothing changed. - George Carlin
=
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 00/16] unify GCC command line options

[Jordan Justen]

On 2015-08-17 11:25:56, Ard Biesheuvel wrote:
 On 17 August 2015 at 20:22, Jordan Justen jordan.l.jus...@intel.com wrote:
  Can't you use an elf-based GCC4.9 with the GCC49 toolchain instead?
 
  I'm not sure it makes sense to 'upgrade' the UNIXGCC toolchain to be
  based on GCC 4.9 rather than 4.3. I think GCC 4.3 was implicitly part
  of the definition of the UNIXGCC toolchain. (Well, maybe explicitly if
  you count the comment in tools_def :) This is why I'd rather deprecate
  it as a toolchain, and use the GCC4X toolchains instead.
 
 
 No, you can't really.
 
 MinGW generates PE/COFF not ELF, so much of the linker command line is
 different, and it really deserves a toolchain of its own

Why does it deserve a toolchain of its own if the other toolchain
produces better code? Why should EDK II care about using the different
linker path if it isn't the best recommended way to build images?

 Making version 4.3.0 part of the definition of UNIXGCC sounds awkward
 to me. In fact, the idea of supporting all toolchains into eternity
 sounds awkward, and it is obviously not working, since many are
 deprecated and don't work at all or only partially. It would be much
 better imo to allow a definition like UNIXGCC to evolve with the state
 of the art

I mostly agree, but I would rather see us add new toolchains and
deprecate the old ones rather than evolving the requirements for a
particular toolchain.

I think the name UNIXGCC is too generic and too short sighted. It made
sense at the time, but I don't think we should keep moving it forward
and turn it into a moving target.

The MYTOOLS toolchain was what you are describing, but for MSVC. It
looks like it is stuck at VS2008 though. Anyway, I guess we should
also deprecate MYTOOLS. :)

-Jordan
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 00/16] unify GCC command line options

[Jordan Justen]

On 2015-08-17 11:25:41, David Woodhouse wrote:
 On Mon, 2015-08-17 at 11:22 -0700, Jordan Justen wrote:
  Can't you use an elf-based GCC4.9 with the GCC49 toolchain instead?
 
 Not for testing LLP64, no.

How/who is this helping?

  I'm not sure it makes sense to 'upgrade' the UNIXGCC toolchain to be
  based on GCC 4.9 rather than 4.3. I think GCC 4.3 was implicitly part
  of the definition of the UNIXGCC toolchain. (Well, maybe explicitly if
  you count the comment in tools_def :) This is why I'd rather deprecate
  it as a toolchain, and use the GCC4X toolchains instead.
 
 Or kill UNIXGCC and replace it with MINGWGCC so the historical baggage
 is lost.

Maybe MINGW49. But, please not before we figure out how to actually
deprecate toolchains. :)

By 'figure out', I mean get to the point where we are okay with
actually deprecating toolchains.

-Jordan
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 00/16] unify GCC command line options

[Ard Biesheuvel]

On 17 August 2015 at 20:22, Jordan Justen jordan.l.jus...@intel.com wrote:
 On 2015-08-17 11:10:57, Bill Paul wrote:
 Of all the gin joints in all the towns in all the world, David Woodhouse had
 to walk into mine at 11:00:23 on Monday 17 August 2015 and say:

  On Mon, 2015-08-17 at 10:53 -0700, Jordan Justen wrote:
   UNIXGCC and CYGGCC are GCC 4.3  mingw based. Did this get tested?
  
   I think ELFGCC is unused at this point. (And has been since UnixPkg
   was deprecated.)
  
   I think we should deprecate all three of these toolchains. I would
   like to see us move them to BaseTools/Conf/tools_def.deprecated. I'll
   add Larry to this email, because I think he disagrees with
   deprecating
   toolchains...
  
   If you make these changes and it breaks those toolchains, I don't
   think we would be able to notice, because I don't think we test them
   in our build pool anymore. To me this is all the more reason to move
   them out of tools_def.template.
 
  I was building with UNIXGCC last week, to test LLP64 builds without the
  pain of actually having to deal with Windows.
 
  I'd rather see it updated to work with modern MinGW rather than
  deprecated.

 I use UNIXGCC with the cross-compiler toolchain generated by mingw-gcc-
 build.py. Yes, I know the existing version of the script uses GCC 4.3.0.
 That's why I made an updated version that uses 4.9.3:

 http://people.freebsd.org/~wpaul/edk2/mingw-gcc-build.py

 I know you don't want to support this script, that's why I did the work for
 you. :) Yes I've tested both IA32 and X64 builds. Yes they work fine.

 There is value in being able to bootstrap your own cross-build toolchain on
 whatever platform. I don't think you should be so quick to remove it.

 Can't you use an elf-based GCC4.9 with the GCC49 toolchain instead?

 I'm not sure it makes sense to 'upgrade' the UNIXGCC toolchain to be
 based on GCC 4.9 rather than 4.3. I think GCC 4.3 was implicitly part
 of the definition of the UNIXGCC toolchain. (Well, maybe explicitly if
 you count the comment in tools_def :) This is why I'd rather deprecate
 it as a toolchain, and use the GCC4X toolchains instead.


No, you can't really.

MinGW generates PE/COFF not ELF, so much of the linker command line is
different, and it really deserves a toolchain of its own

Making version 4.3.0 part of the definition of UNIXGCC sounds awkward
to me. In fact, the idea of supporting all toolchains into eternity
sounds awkward, and it is obviously not working, since many are
deprecated and don't work at all or only partially. It would be much
better imo to allow a definition like UNIXGCC to evolve with the state
of the art
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 00/16] unify GCC command line options

[David Woodhouse]

On Mon, 2015-08-17 at 11:22 -0700, Jordan Justen wrote:
 Can't you use an elf-based GCC4.9 with the GCC49 toolchain instead?

Not for testing LLP64, no.

 I'm not sure it makes sense to 'upgrade' the UNIXGCC toolchain to be
 based on GCC 4.9 rather than 4.3. I think GCC 4.3 was implicitly part
 of the definition of the UNIXGCC toolchain. (Well, maybe explicitly if
 you count the comment in tools_def :) This is why I'd rather deprecate
 it as a toolchain, and use the GCC4X toolchains instead.

Or kill UNIXGCC and replace it with MINGWGCC so the historical baggage
is lost.

-- 
dwmw2




smime.p7s
Description: S/MIME cryptographic signature
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 00/16] unify GCC command line options

[David Woodhouse]

See http://www.infradead.org/rpr.html
X-SRS-Rewrite: SMTP reverse-path rewritten from dw...@infradead.org by 
twosheds.infradead.org
See http://www.infradead.org/rpr.html


 On 2015-08-17 11:25:41, David Woodhouse wrote:
 On Mon, 2015-08-17 at 11:22 -0700, Jordan Justen wrote:
  Can't you use an elf-based GCC4.9 with the GCC49 toolchain instead?

 Not for testing LLP64, no.

 How/who is this helping?

It was massively useful for testing the OpenSSL stuff I've been working on
recently. It showed up a number of issues which would otherwise only occur
a Windows build.

  I'm not sure it makes sense to 'upgrade' the UNIXGCC toolchain to be
  based on GCC 4.9 rather than 4.3. I think GCC 4.3 was implicitly part
  of the definition of the UNIXGCC toolchain. (Well, maybe explicitly if
  you count the comment in tools_def :) This is why I'd rather deprecate
  it as a toolchain, and use the GCC4X toolchains instead.

 Or kill UNIXGCC and replace it with MINGWGCC so the historical baggage
 is lost.

 Maybe MINGW49. But, please not before we figure out how to actually
 deprecate toolchains. :)

 By 'figure out', I mean get to the point where we are okay with
 actually deprecating toolchains.

Deprecating toolchains is pointless until we can ditch the badly
maintained 20th century crap that holds us back from using C99 code. Once
we have the political will to say here's a nickel, kid. Buy yourself a
real compiler and provide Windows-hosted GCC or LLVM based toolchains,
there really is no point.


-- 
dwmw2

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel