Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
7800026:
Fix nacl_helper argv bug, re-enable, build on linux except ARM (Closed)
|
Created:
9 years, 3 months ago by Brad Chen Modified:
9 years, 3 months ago Reviewers:
Mattias Nissler (ping if slow), Dmitry Polukhin, khimg, Use chromium.org instead, commit-bot: I haz the power, raymes, evanm, Mark Seaborn CC:
chromium-reviews, native-client-reviews_googlegroups.com, bjanakiraman Base URL:
svn://svn.chromium.org/chrome/trunk/src Visibility:
Public. |
DescriptionFix nacl_helper argv bug, re-enable nacl_helper, build on linux except ARM. Previously reviewed as http://codereview.chromium.org/7833017; this time ARM build is disabled.
TBR=mcgrathr,mseaborn,evanm
BUG=92964, nativeclient:480, 95196
TEST=nacl_integration on linux
Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=99622
Patch Set 1 #
Messages
Total messages: 27 (0 generated)
No reviewers yet.
No LGTM from valid reviewers yet.
I see several problems due to this commit: - It breaks the build on Chrome OS for me, generating this message: /home/mnissler/chrome_root/src/c/Debug/nacl_helper_bootstrap_munge_phdr: Program header 1 has nonzero p_filesz - it doesn't honor disable_nacl=1 (i.e. the build still breaks even if I disable NaCl) - and a nit: the change you introduced in chrome_exe.gypi contains tabs :)
Bot that is broken: http://build.chromium.org/p/chromiumos/builders/x86%20generic%20TOT%20chrome%... Top build nacl we need bunutils 2.21.1 but it doesn't exist in chroot.
On Mon, Sep 5, 2011 at 2:31 PM, <dpolukhin@chromium.org> wrote: > Bot that is broken: > http://build.chromium.org/p/**chromiumos/builders/x86%** > 20generic%20TOT%20chrome%**20PFQ/builds/863/steps/**BuildTarget/logs/stdio<http://build.chromium.org/p/chromiumos/builders/x86%20generic%20TOT%20chrome%20PFQ/builds/863/steps/BuildTarget/logs/stdio> > > Top build nacl we need bunutils 2.21.1 but it doesn't exist in chroot. Note I've updated gold locally, but still get the errors I originally mentioned. Ld version for reference: (cros-chroot) mnissler@tui ~/trunk/src/scripts $ ld --version GNU ld (GNU Binutils) 2.21.1 Copyright 2011 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) a later version. This program has absolutely no warranty. > > > http://codereview.chromium.**org/7800026/<http://codereview.chromium.org/7800... > -- You received this message because you are subscribed to the Google Groups "Native-Client-Reviews" group. To post to this group, send email to native-client-reviews@googlegroups.com. To unsubscribe from this group, send email to native-client-reviews+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/native-client-reviews?hl=en.
On Mon, Sep 5, 2011 at 2:31 PM, <dpolukhin@chromium.org> wrote: > Bot that is broken: > http://build.chromium.org/p/**chromiumos/builders/x86%** > 20generic%20TOT%20chrome%**20PFQ/builds/863/steps/**BuildTarget/logs/stdio<http://build.chromium.org/p/chromiumos/builders/x86%20generic%20TOT%20chrome%20PFQ/builds/863/steps/BuildTarget/logs/stdio> > > Top build nacl we need bunutils 2.21.1 but it doesn't exist in chroot. Note I've updated gold locally, but still get the errors I originally mentioned. Ld version for reference: (cros-chroot) mnissler@tui ~/trunk/src/scripts $ ld --version GNU ld (GNU Binutils) 2.21.1 Copyright 2011 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) a later version. This program has absolutely no warranty. > > > http://codereview.chromium.**org/7800026/<http://codereview.chromium.org/7800... >
I think the problem is that this build is trying to link nacl_bootstrap_helper_raw with gold. That won't work; gold doesn't properly implement some of the flags required to link this program. The build expects the BFD loader to be available in /usr/bin/ld.bfd. This is the normal place that the 'old' loader is available when gold is installed. See src/tools/ld_bfd/ld in the chromium tree. Brad On Mon, Sep 5, 2011 at 5:45 AM, Mattias Nissler <mnissler@chromium.org>wrote: > On Mon, Sep 5, 2011 at 2:31 PM, <dpolukhin@chromium.org> wrote: > >> Bot that is broken: >> http://build.chromium.org/p/**chromiumos/builders/x86%** >> 20generic%20TOT%20chrome%**20PFQ/builds/863/steps/** >> BuildTarget/logs/stdio<http://build.chromium.org/p/chromiumos/builders/x86%20generic%20TOT%20chrome%20PFQ/builds/863/steps/BuildTarget/logs/stdio> >> >> Top build nacl we need bunutils 2.21.1 but it doesn't exist in chroot. > > > Note I've updated gold locally, but still get the errors I originally > mentioned. Ld version for reference: > > (cros-chroot) mnissler@tui ~/trunk/src/scripts $ ld --version > GNU ld (GNU Binutils) 2.21.1 > Copyright 2011 Free Software Foundation, Inc. > This program is free software; you may redistribute it under the terms of > the GNU General Public License version 3 or (at your option) a later > version. > This program has absolutely no warranty. > > > >> >> >> http://codereview.chromium.**org/7800026/<http://codereview.chromium.org/7800... >> > > -- You received this message because you are subscribed to the Google Groups "Native-Client-Reviews" group. To post to this group, send email to native-client-reviews@googlegroups.com. To unsubscribe from this group, send email to native-client-reviews+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/native-client-reviews?hl=en.
I think the problem is that this build is trying to link nacl_bootstrap_helper_raw with gold. That won't work; gold doesn't properly implement some of the flags required to link this program. The build expects the BFD loader to be available in /usr/bin/ld.bfd. This is the normal place that the 'old' loader is available when gold is installed. See src/tools/ld_bfd/ld in the chromium tree. Brad On Mon, Sep 5, 2011 at 5:45 AM, Mattias Nissler <mnissler@chromium.org>wrote: > On Mon, Sep 5, 2011 at 2:31 PM, <dpolukhin@chromium.org> wrote: > >> Bot that is broken: >> http://build.chromium.org/p/**chromiumos/builders/x86%** >> 20generic%20TOT%20chrome%**20PFQ/builds/863/steps/** >> BuildTarget/logs/stdio<http://build.chromium.org/p/chromiumos/builders/x86%20generic%20TOT%20chrome%20PFQ/builds/863/steps/BuildTarget/logs/stdio> >> >> Top build nacl we need bunutils 2.21.1 but it doesn't exist in chroot. > > > Note I've updated gold locally, but still get the errors I originally > mentioned. Ld version for reference: > > (cros-chroot) mnissler@tui ~/trunk/src/scripts $ ld --version > GNU ld (GNU Binutils) 2.21.1 > Copyright 2011 Free Software Foundation, Inc. > This program is free software; you may redistribute it under the terms of > the GNU General Public License version 3 or (at your option) a later > version. > This program has absolutely no warranty. > > > >> >> >> http://codereview.chromium.**org/7800026/<http://codereview.chromium.org/7800... >> > >
It looks like, in the link command for nacl_bootstrap_helper_raw, it is specifying the -B argument twice; bad. It should only appear once, for tools/ld_bfd. I believe as a consequence, the build is attempting to use gold rather than ld.bfd to link. This will not work. Need to use ld.bfd. Brad chromeos-chrome-15.0.873.0_alpha-r1: flock c/Release/linker.lock i686-pc-linux\ -gnu-g++ -B/usr/x86_64-pc-linux-gnu/i686-pc-linux-gnu/binutils-bin/2.20.1-gold -\ pthread -Wl,-z,noexecstack -m32 -B tools/ld_bfd -static -nostartfiles -Wl,--scri\ pt=chrome/nacl/nacl_helper_bootstrap_linux.x -Wl,-z,max-page-size=0x1000 --sysro\ ot=/build/x86-generic/ -Wl,-O1 -Wl,--as-needed -Wl,--gc-sections -o c/Release/\ nacl_helper_bootstrap_raw -Wl,--start-group c/Release/obj.target/nacl_helper_boo\ tstrap_raw/chrome/nacl/nacl_helper_bootstrap_linux.o -Wl,--end-group On Mon, Sep 5, 2011 at 9:01 AM, Brad Chen <bradchen@google.com> wrote: > I think the problem is that this build is trying to link > nacl_bootstrap_helper_raw with gold. That won't work; gold doesn't properly > implement some of the flags required to link this program. The build expects > the BFD loader to be available in /usr/bin/ld.bfd. This is the normal place > that the 'old' loader is available when gold is installed. See > src/tools/ld_bfd/ld in the chromium tree. > > Brad > > > On Mon, Sep 5, 2011 at 5:45 AM, Mattias Nissler <mnissler@chromium.org>wrote: > >> On Mon, Sep 5, 2011 at 2:31 PM, <dpolukhin@chromium.org> wrote: >> >>> Bot that is broken: >>> http://build.chromium.org/p/**chromiumos/builders/x86%** >>> 20generic%20TOT%20chrome%**20PFQ/builds/863/steps/** >>> BuildTarget/logs/stdio<http://build.chromium.org/p/chromiumos/builders/x86%20generic%20TOT%20chrome%20PFQ/builds/863/steps/BuildTarget/logs/stdio> >>> >>> Top build nacl we need bunutils 2.21.1 but it doesn't exist in chroot. >> >> >> Note I've updated gold locally, but still get the errors I originally >> mentioned. Ld version for reference: >> >> (cros-chroot) mnissler@tui ~/trunk/src/scripts $ ld --version >> GNU ld (GNU Binutils) 2.21.1 >> Copyright 2011 Free Software Foundation, Inc. >> This program is free software; you may redistribute it under the terms of >> the GNU General Public License version 3 or (at your option) a later >> version. >> This program has absolutely no warranty. >> >> >> >>> >>> >>> http://codereview.chromium.**org/7800026/<http://codereview.chromium.org/7800... >>> >> >> > -- You received this message because you are subscribed to the Google Groups "Native-Client-Reviews" group. To post to this group, send email to native-client-reviews@googlegroups.com. To unsubscribe from this group, send email to native-client-reviews+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/native-client-reviews?hl=en.
It looks like, in the link command for nacl_bootstrap_helper_raw, it is specifying the -B argument twice; bad. It should only appear once, for tools/ld_bfd. I believe as a consequence, the build is attempting to use gold rather than ld.bfd to link. This will not work. Need to use ld.bfd. Brad chromeos-chrome-15.0.873.0_alpha-r1: flock c/Release/linker.lock i686-pc-linux\ -gnu-g++ -B/usr/x86_64-pc-linux-gnu/i686-pc-linux-gnu/binutils-bin/2.20.1-gold -\ pthread -Wl,-z,noexecstack -m32 -B tools/ld_bfd -static -nostartfiles -Wl,--scri\ pt=chrome/nacl/nacl_helper_bootstrap_linux.x -Wl,-z,max-page-size=0x1000 --sysro\ ot=/build/x86-generic/ -Wl,-O1 -Wl,--as-needed -Wl,--gc-sections -o c/Release/\ nacl_helper_bootstrap_raw -Wl,--start-group c/Release/obj.target/nacl_helper_boo\ tstrap_raw/chrome/nacl/nacl_helper_bootstrap_linux.o -Wl,--end-group On Mon, Sep 5, 2011 at 9:01 AM, Brad Chen <bradchen@google.com> wrote: > I think the problem is that this build is trying to link > nacl_bootstrap_helper_raw with gold. That won't work; gold doesn't properly > implement some of the flags required to link this program. The build expects > the BFD loader to be available in /usr/bin/ld.bfd. This is the normal place > that the 'old' loader is available when gold is installed. See > src/tools/ld_bfd/ld in the chromium tree. > > Brad > > > On Mon, Sep 5, 2011 at 5:45 AM, Mattias Nissler <mnissler@chromium.org>wrote: > >> On Mon, Sep 5, 2011 at 2:31 PM, <dpolukhin@chromium.org> wrote: >> >>> Bot that is broken: >>> http://build.chromium.org/p/**chromiumos/builders/x86%** >>> 20generic%20TOT%20chrome%**20PFQ/builds/863/steps/** >>> BuildTarget/logs/stdio<http://build.chromium.org/p/chromiumos/builders/x86%20generic%20TOT%20chrome%20PFQ/builds/863/steps/BuildTarget/logs/stdio> >>> >>> Top build nacl we need bunutils 2.21.1 but it doesn't exist in chroot. >> >> >> Note I've updated gold locally, but still get the errors I originally >> mentioned. Ld version for reference: >> >> (cros-chroot) mnissler@tui ~/trunk/src/scripts $ ld --version >> GNU ld (GNU Binutils) 2.21.1 >> Copyright 2011 Free Software Foundation, Inc. >> This program is free software; you may redistribute it under the terms of >> the GNU General Public License version 3 or (at your option) a later >> version. >> This program has absolutely no warranty. >> >> >> >>> >>> >>> http://codereview.chromium.**org/7800026/<http://codereview.chromium.org/7800... >>> >> >> >
The problem is that the chrome ebuild also uses the -B flag to select gold. Since the host-built cross-compiler knows nothing about this new ld_bfd linker, does it make more sense to invoke the linker directly rather than through the gcc driver? Or is there a nacl gcc driver that should be used to invoke this linker? We need to look at the possibility of unifying the NaCl/ChromeOS toolchains in some way.
On Mon, Sep 5, 2011 at 9:42 PM, <raymes@chromium.org> wrote: > The problem is that the chrome ebuild also uses the -B flag to select gold. > > Since the host-built cross-compiler knows nothing about this new ld_bfd > linker, > It's kind of funny when you call twenty years old linker "new". > does it make more sense to invoke the linker directly rather than through > the > gcc driver? There are nothing wrong with using gcc driver here: it knows where to find various start files and libraries, we don't. The problem lies with gold: it's 98% compatible with classic ld, not 100% compatible and thus you need good, old, classic ld to link nacl_helper. > Or is there a nacl gcc driver that should be used to invoke this > linker? > > Standard gcc driver was using this linker by default for last 20 years. It's designed to support it very wll indeed. In fact it still uses it by default unless instructed to do something different with compile-time or run-time option. The ld_bfd hack is just to make sure good old linker will be used by default even if GCC is compiled with different options. It's necessary. If ChromeOS uses different mechanisms to use old BFD linker, that said mechanism can be used instead. Just make sure you are using BFD ld with nacl_helper and this should fix the problem. We need to look at the possibility of unifying the NaCl/ChromeOS toolchains > in > some way. > > NaCl toochain is for compiling untrusted code. It does not even use the same memory model (x86-32 changes are tiny, but x86-64 are substantial: for example host compiler uses LP64 while nacl compiler uses ILP32). Yes, it also currently uses old BFD linker, not gold, but it makes as much sense to use it as to use FreeBSD or Solaris toolchain: they have nothing to do with Linux, they are for different platforms altogether. -- You received this message because you are subscribed to the Google Groups "Native-Client-Reviews" group. To post to this group, send email to native-client-reviews@googlegroups.com. To unsubscribe from this group, send email to native-client-reviews+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/native-client-reviews?hl=en.
On Mon, Sep 5, 2011 at 9:42 PM, <raymes@chromium.org> wrote: > The problem is that the chrome ebuild also uses the -B flag to select gold. > > Since the host-built cross-compiler knows nothing about this new ld_bfd > linker, > It's kind of funny when you call twenty years old linker "new". > does it make more sense to invoke the linker directly rather than through > the > gcc driver? There are nothing wrong with using gcc driver here: it knows where to find various start files and libraries, we don't. The problem lies with gold: it's 98% compatible with classic ld, not 100% compatible and thus you need good, old, classic ld to link nacl_helper. > Or is there a nacl gcc driver that should be used to invoke this > linker? > > Standard gcc driver was using this linker by default for last 20 years. It's designed to support it very wll indeed. In fact it still uses it by default unless instructed to do something different with compile-time or run-time option. The ld_bfd hack is just to make sure good old linker will be used by default even if GCC is compiled with different options. It's necessary. If ChromeOS uses different mechanisms to use old BFD linker, that said mechanism can be used instead. Just make sure you are using BFD ld with nacl_helper and this should fix the problem. We need to look at the possibility of unifying the NaCl/ChromeOS toolchains > in > some way. > > NaCl toochain is for compiling untrusted code. It does not even use the same memory model (x86-32 changes are tiny, but x86-64 are substantial: for example host compiler uses LP64 while nacl compiler uses ILP32). Yes, it also currently uses old BFD linker, not gold, but it makes as much sense to use it as to use FreeBSD or Solaris toolchain: they have nothing to do with Linux, they are for different platforms altogether.
Can you use -fuse-ld=ld-bfd option to force use of ld.bfd, or does this not help? Bhaskar On Mon, Sep 5, 2011 at 10:42 AM, <raymes@chromium.org> wrote: > The problem is that the chrome ebuild also uses the -B flag to select gold. > > Since the host-built cross-compiler knows nothing about this new ld_bfd > linker, > does it make more sense to invoke the linker directly rather than through > the > gcc driver? Or is there a nacl gcc driver that should be used to invoke > this > linker? > > We need to look at the possibility of unifying the NaCl/ChromeOS toolchains > in > some way. > > http://codereview.chromium.**org/7800026/<http://codereview.chromium.org/7800... > -- You received this message because you are subscribed to the Google Groups "Native-Client-Reviews" group. To post to this group, send email to native-client-reviews@googlegroups.com. To unsubscribe from this group, send email to native-client-reviews+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/native-client-reviews?hl=en.
Can you use -fuse-ld=ld-bfd option to force use of ld.bfd, or does this not help? Bhaskar On Mon, Sep 5, 2011 at 10:42 AM, <raymes@chromium.org> wrote: > The problem is that the chrome ebuild also uses the -B flag to select gold. > > Since the host-built cross-compiler knows nothing about this new ld_bfd > linker, > does it make more sense to invoke the linker directly rather than through > the > gcc driver? Or is there a nacl gcc driver that should be used to invoke > this > linker? > > We need to look at the possibility of unifying the NaCl/ChromeOS toolchains > in > some way. > > http://codereview.chromium.**org/7800026/<http://codereview.chromium.org/7800... >
-fuse-ld=bfd would allow us to work around the problem by changing the chrome ebuild but there are problems with that approach as well. Last time I checked, we did not have the patch to allow -fuse-ld in gcc-4.6. There are other workarounds for this (e.g. add a custom flag to the sysroot wrapper). We need to discuss what the best approach is for specifying custom linkers. Raymes On Mon, Sep 5, 2011 at 5:57 PM, Bhaskar Janakiraman <bjanakiraman@google.com> wrote: > Can you use -fuse-ld=ld-bfd option to force use of ld.bfd, or does this not > help? > Bhaskar > > On Mon, Sep 5, 2011 at 10:42 AM, <raymes@chromium.org> wrote: >> >> The problem is that the chrome ebuild also uses the -B flag to select >> gold. >> >> Since the host-built cross-compiler knows nothing about this new ld_bfd >> linker, >> does it make more sense to invoke the linker directly rather than through >> the >> gcc driver? Or is there a nacl gcc driver that should be used to invoke >> this >> linker? >> >> We need to look at the possibility of unifying the NaCl/ChromeOS >> toolchains in >> some way. >> >> http://codereview.chromium.org/7800026/ > > -- You received this message because you are subscribed to the Google Groups "Native-Client-Reviews" group. To post to this group, send email to native-client-reviews@googlegroups.com. To unsubscribe from this group, send email to native-client-reviews+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/native-client-reviews?hl=en.
-fuse-ld=bfd would allow us to work around the problem by changing the chrome ebuild but there are problems with that approach as well. Last time I checked, we did not have the patch to allow -fuse-ld in gcc-4.6. There are other workarounds for this (e.g. add a custom flag to the sysroot wrapper). We need to discuss what the best approach is for specifying custom linkers. Raymes On Mon, Sep 5, 2011 at 5:57 PM, Bhaskar Janakiraman <bjanakiraman@google.com> wrote: > Can you use -fuse-ld=ld-bfd option to force use of ld.bfd, or does this not > help? > Bhaskar > > On Mon, Sep 5, 2011 at 10:42 AM, <raymes@chromium.org> wrote: >> >> The problem is that the chrome ebuild also uses the -B flag to select >> gold. >> >> Since the host-built cross-compiler knows nothing about this new ld_bfd >> linker, >> does it make more sense to invoke the linker directly rather than through >> the >> gcc driver? Or is there a nacl gcc driver that should be used to invoke >> this >> linker? >> >> We need to look at the possibility of unifying the NaCl/ChromeOS >> toolchains in >> some way. >> >> http://codereview.chromium.org/7800026/ > >
Background: This doesn't have anything to do with the nacl tools. We are using ld.bfd to build a Linux executable with a slightly tweaked memory layout, needed to properly initialize the address space on Chrome OS. We need to use the BFD loader because current releases of gold don't implement the -T flag properly. Although Ian Taylor has fixed that bug for us, I don't expect the fix has made it into a binutils release yet. Thinking about this while traveling today, I don't understand why the Chrome OS build selects gold as it does using all the environment variables plus the -B flag. This seems much more complex and less robust than the common practice of a soft link from /usr/bin/ld to gold. With the common approach everything uses gold by default, but the BFD loader is still available as ld.bfd. Since you're building in a chroot environment the soft link from /usr/bin/ld seems that much more practical. Asking myself why you would do something different, I thought perhaps you wanted to avoid replacing /usr/bin/ld, so that the BFD loader would be available in that location. Except what you have achieved instead is the opposite, making it effectively impossible to specify the BFD loader during a GYP build. It may be possible to specify a load commend in GYP however this is more GYP wizardry than I had at my disposal at the time. Given the way that GYP sometimes seems specific to what Chrome needs, it may be that this feature is not yet supported. This and your -fuse= suggestion I will look into first thing tomorrow morning. I'm not familiar with -fuse-ld, this is a recent gcc option? Brad On Mon, Sep 5, 2011 at 6:39 PM, Raymes Khoury <raymes@chromium.org> wrote: > -fuse-ld=bfd would allow us to work around the problem by changing the > chrome ebuild but there are problems with that approach as well. Last > time I checked, we did not have the patch to allow -fuse-ld in > gcc-4.6. > > There are other workarounds for this (e.g. add a custom flag to the > sysroot wrapper). We need to discuss what the best approach is for > specifying custom linkers. > > Raymes > > On Mon, Sep 5, 2011 at 5:57 PM, Bhaskar Janakiraman > <bjanakiraman@google.com> wrote: > > Can you use -fuse-ld=ld-bfd option to force use of ld.bfd, or does this > not > > help? > > Bhaskar > > > > On Mon, Sep 5, 2011 at 10:42 AM, <raymes@chromium.org> wrote: > >> > >> The problem is that the chrome ebuild also uses the -B flag to select > >> gold. > >> > >> Since the host-built cross-compiler knows nothing about this new ld_bfd > >> linker, > >> does it make more sense to invoke the linker directly rather than > through > >> the > >> gcc driver? Or is there a nacl gcc driver that should be used to invoke > >> this > >> linker? > >> > >> We need to look at the possibility of unifying the NaCl/ChromeOS > >> toolchains in > >> some way. > >> > >> http://codereview.chromium.org/7800026/ > > > > > -- You received this message because you are subscribed to the Google Groups "Native-Client-Reviews" group. To post to this group, send email to native-client-reviews@googlegroups.com. To unsubscribe from this group, send email to native-client-reviews+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/native-client-reviews?hl=en.
Background: This doesn't have anything to do with the nacl tools. We are using ld.bfd to build a Linux executable with a slightly tweaked memory layout, needed to properly initialize the address space on Chrome OS. We need to use the BFD loader because current releases of gold don't implement the -T flag properly. Although Ian Taylor has fixed that bug for us, I don't expect the fix has made it into a binutils release yet. Thinking about this while traveling today, I don't understand why the Chrome OS build selects gold as it does using all the environment variables plus the -B flag. This seems much more complex and less robust than the common practice of a soft link from /usr/bin/ld to gold. With the common approach everything uses gold by default, but the BFD loader is still available as ld.bfd. Since you're building in a chroot environment the soft link from /usr/bin/ld seems that much more practical. Asking myself why you would do something different, I thought perhaps you wanted to avoid replacing /usr/bin/ld, so that the BFD loader would be available in that location. Except what you have achieved instead is the opposite, making it effectively impossible to specify the BFD loader during a GYP build. It may be possible to specify a load commend in GYP however this is more GYP wizardry than I had at my disposal at the time. Given the way that GYP sometimes seems specific to what Chrome needs, it may be that this feature is not yet supported. This and your -fuse= suggestion I will look into first thing tomorrow morning. I'm not familiar with -fuse-ld, this is a recent gcc option? Brad On Mon, Sep 5, 2011 at 6:39 PM, Raymes Khoury <raymes@chromium.org> wrote: > -fuse-ld=bfd would allow us to work around the problem by changing the > chrome ebuild but there are problems with that approach as well. Last > time I checked, we did not have the patch to allow -fuse-ld in > gcc-4.6. > > There are other workarounds for this (e.g. add a custom flag to the > sysroot wrapper). We need to discuss what the best approach is for > specifying custom linkers. > > Raymes > > On Mon, Sep 5, 2011 at 5:57 PM, Bhaskar Janakiraman > <bjanakiraman@google.com> wrote: > > Can you use -fuse-ld=ld-bfd option to force use of ld.bfd, or does this > not > > help? > > Bhaskar > > > > On Mon, Sep 5, 2011 at 10:42 AM, <raymes@chromium.org> wrote: > >> > >> The problem is that the chrome ebuild also uses the -B flag to select > >> gold. > >> > >> Since the host-built cross-compiler knows nothing about this new ld_bfd > >> linker, > >> does it make more sense to invoke the linker directly rather than > through > >> the > >> gcc driver? Or is there a nacl gcc driver that should be used to invoke > >> this > >> linker? > >> > >> We need to look at the possibility of unifying the NaCl/ChromeOS > >> toolchains in > >> some way. > >> > >> http://codereview.chromium.org/7800026/ > > > > >
Thanks for the clarification! > Background: This doesn't have anything to do with the nacl tools. We are > using ld.bfd to build a Linux executable with a slightly tweaked memory > layout, needed to properly initialize the address space on Chrome OS. We > need to use the BFD loader because current releases of gold don't implement > the -T flag properly. Although Ian Taylor has fixed that bug for us, I don't > expect the fix has made it into a binutils release yet. I see and I just took a look at the ld_bfd wrapper script (http://src.chromium.org/viewvc/chrome/trunk/src/tools/ld_bfd/ld). That wrapper script might fail for ChromeOS anyway, because our linker is not installed in /usr/bin/ld. We have cross-compilers and they are installed in /usr/bin/[target-arch]-ld. Even worse, it may appear to work but use the host-linker instead of the cross-linker. > Thinking about this while traveling today, I don't understand why the Chrome > OS build selects gold as it does using all the environment variables plus > the -B flag. This seems much more complex and less robust than the common > practice of a soft link from /usr/bin/ld to gold. With the common approach > everything uses gold by default, but the BFD loader is still available as > ld.bfd. Since you're building in a chroot environment the soft link from > /usr/bin/ld seems that much more practical. > Asking myself why you would do something different, I thought perhaps you > wanted to avoid replacing /usr/bin/ld, so that the BFD loader would be > available in that location. Yes, we do indeed create a soft-link as you say but the situation is more complicated than that. For x86, the file /usr/bin/i686-pc-linux-gnu-ld does indeed point to gold, as you suggest. For ARM, however, it does not because GNU ld is still the default for ARM (but we build chrome with gold). Also a handful of other packages fail to build with gold so we need a way to use bfd. This is why we use the -B flag in other ebuilds. Basically we face the same problem as you, which is that the only supported way of switching linkers is with -B and that isn't a very good mechanism (as shown here). > Except what you have achieved instead is the > opposite, making it effectively impossible to specify the BFD loader during > a GYP build. Yes that is true, but this is a problem with the mechanism for selecting a linker and has nothing to do with what the default linker is. > It may be possible to specify a load commend in GYP however this is more GYP > wizardry than I had at my disposal at the time. Given the way that GYP > sometimes seems specific to what Chrome needs, it may be that this feature > is not yet supported. This and your -fuse= suggestion I will look into first > thing tomorrow morning. I'm not familiar with -fuse-ld, this is a recent gcc > option? -fuse-ld does solve this problem but last time I checked, it was a patch that was not comitted upstream (it was still pending). Moreover, it had a bug in it. In any case, we can provide a solution to make it easy to select ld.bfd in the gyp, if that's what you want to achieve (at least for ChromeOS). I'll discuss with the toolchain team tomorrow how we want to do this (whether it be to use fuse-ld or some other mechanism). Another thing we may want to do is to backport the patch you need for gold, which we can do relatively quickly, but this would only sidestep the linker selection issue. Thanks, Raymes On Mon, Sep 5, 2011 at 9:45 PM, Brad Chen <bradchen@google.com> wrote: > Background: This doesn't have anything to do with the nacl tools. We are > using ld.bfd to build a Linux executable with a slightly tweaked memory > layout, needed to properly initialize the address space on Chrome OS. We > need to use the BFD loader because current releases of gold don't implement > the -T flag properly. Although Ian Taylor has fixed that bug for us, I don't > expect the fix has made it into a binutils release yet. > Thinking about this while traveling today, I don't understand why the Chrome > OS build selects gold as it does using all the environment variables plus > the -B flag. This seems much more complex and less robust than the common > practice of a soft link from /usr/bin/ld to gold. With the common approach > everything uses gold by default, but the BFD loader is still available as > ld.bfd. Since you're building in a chroot environment the soft link from > /usr/bin/ld seems that much more practical. > Asking myself why you would do something different, I thought perhaps you > wanted to avoid replacing /usr/bin/ld, so that the BFD loader would be > available in that location. Except what you have achieved instead is the > opposite, making it effectively impossible to specify the BFD loader during > a GYP build. > It may be possible to specify a load commend in GYP however this is more GYP > wizardry than I had at my disposal at the time. Given the way that GYP > sometimes seems specific to what Chrome needs, it may be that this feature > is not yet supported. This and your -fuse= suggestion I will look into first > thing tomorrow morning. I'm not familiar with -fuse-ld, this is a recent gcc > option? > Brad > > On Mon, Sep 5, 2011 at 6:39 PM, Raymes Khoury <raymes@chromium.org> wrote: >> >> -fuse-ld=bfd would allow us to work around the problem by changing the >> chrome ebuild but there are problems with that approach as well. Last >> time I checked, we did not have the patch to allow -fuse-ld in >> gcc-4.6. >> >> There are other workarounds for this (e.g. add a custom flag to the >> sysroot wrapper). We need to discuss what the best approach is for >> specifying custom linkers. >> >> Raymes >> >> On Mon, Sep 5, 2011 at 5:57 PM, Bhaskar Janakiraman >> <bjanakiraman@google.com> wrote: >> > Can you use -fuse-ld=ld-bfd option to force use of ld.bfd, or does this >> > not >> > help? >> > Bhaskar >> > >> > On Mon, Sep 5, 2011 at 10:42 AM, <raymes@chromium.org> wrote: >> >> >> >> The problem is that the chrome ebuild also uses the -B flag to select >> >> gold. >> >> >> >> Since the host-built cross-compiler knows nothing about this new ld_bfd >> >> linker, >> >> does it make more sense to invoke the linker directly rather than >> >> through >> >> the >> >> gcc driver? Or is there a nacl gcc driver that should be used to invoke >> >> this >> >> linker? >> >> >> >> We need to look at the possibility of unifying the NaCl/ChromeOS >> >> toolchains in >> >> some way. >> >> >> >> http://codereview.chromium.org/7800026/ >> > >> > > >
Thanks for the clarification! > Background: This doesn't have anything to do with the nacl tools. We are > using ld.bfd to build a Linux executable with a slightly tweaked memory > layout, needed to properly initialize the address space on Chrome OS. We > need to use the BFD loader because current releases of gold don't implement > the -T flag properly. Although Ian Taylor has fixed that bug for us, I don't > expect the fix has made it into a binutils release yet. I see and I just took a look at the ld_bfd wrapper script (http://src.chromium.org/viewvc/chrome/trunk/src/tools/ld_bfd/ld). That wrapper script might fail for ChromeOS anyway, because our linker is not installed in /usr/bin/ld. We have cross-compilers and they are installed in /usr/bin/[target-arch]-ld. Even worse, it may appear to work but use the host-linker instead of the cross-linker. > Thinking about this while traveling today, I don't understand why the Chrome > OS build selects gold as it does using all the environment variables plus > the -B flag. This seems much more complex and less robust than the common > practice of a soft link from /usr/bin/ld to gold. With the common approach > everything uses gold by default, but the BFD loader is still available as > ld.bfd. Since you're building in a chroot environment the soft link from > /usr/bin/ld seems that much more practical. > Asking myself why you would do something different, I thought perhaps you > wanted to avoid replacing /usr/bin/ld, so that the BFD loader would be > available in that location. Yes, we do indeed create a soft-link as you say but the situation is more complicated than that. For x86, the file /usr/bin/i686-pc-linux-gnu-ld does indeed point to gold, as you suggest. For ARM, however, it does not because GNU ld is still the default for ARM (but we build chrome with gold). Also a handful of other packages fail to build with gold so we need a way to use bfd. This is why we use the -B flag in other ebuilds. Basically we face the same problem as you, which is that the only supported way of switching linkers is with -B and that isn't a very good mechanism (as shown here). > Except what you have achieved instead is the > opposite, making it effectively impossible to specify the BFD loader during > a GYP build. Yes that is true, but this is a problem with the mechanism for selecting a linker and has nothing to do with what the default linker is. > It may be possible to specify a load commend in GYP however this is more GYP > wizardry than I had at my disposal at the time. Given the way that GYP > sometimes seems specific to what Chrome needs, it may be that this feature > is not yet supported. This and your -fuse= suggestion I will look into first > thing tomorrow morning. I'm not familiar with -fuse-ld, this is a recent gcc > option? -fuse-ld does solve this problem but last time I checked, it was a patch that was not comitted upstream (it was still pending). Moreover, it had a bug in it. In any case, we can provide a solution to make it easy to select ld.bfd in the gyp, if that's what you want to achieve (at least for ChromeOS). I'll discuss with the toolchain team tomorrow how we want to do this (whether it be to use fuse-ld or some other mechanism). Another thing we may want to do is to backport the patch you need for gold, which we can do relatively quickly, but this would only sidestep the linker selection issue. Thanks, Raymes On Mon, Sep 5, 2011 at 9:45 PM, Brad Chen <bradchen@google.com> wrote: > Background: This doesn't have anything to do with the nacl tools. We are > using ld.bfd to build a Linux executable with a slightly tweaked memory > layout, needed to properly initialize the address space on Chrome OS. We > need to use the BFD loader because current releases of gold don't implement > the -T flag properly. Although Ian Taylor has fixed that bug for us, I don't > expect the fix has made it into a binutils release yet. > Thinking about this while traveling today, I don't understand why the Chrome > OS build selects gold as it does using all the environment variables plus > the -B flag. This seems much more complex and less robust than the common > practice of a soft link from /usr/bin/ld to gold. With the common approach > everything uses gold by default, but the BFD loader is still available as > ld.bfd. Since you're building in a chroot environment the soft link from > /usr/bin/ld seems that much more practical. > Asking myself why you would do something different, I thought perhaps you > wanted to avoid replacing /usr/bin/ld, so that the BFD loader would be > available in that location. Except what you have achieved instead is the > opposite, making it effectively impossible to specify the BFD loader during > a GYP build. > It may be possible to specify a load commend in GYP however this is more GYP > wizardry than I had at my disposal at the time. Given the way that GYP > sometimes seems specific to what Chrome needs, it may be that this feature > is not yet supported. This and your -fuse= suggestion I will look into first > thing tomorrow morning. I'm not familiar with -fuse-ld, this is a recent gcc > option? > Brad > > On Mon, Sep 5, 2011 at 6:39 PM, Raymes Khoury <raymes@chromium.org> wrote: >> >> -fuse-ld=bfd would allow us to work around the problem by changing the >> chrome ebuild but there are problems with that approach as well. Last >> time I checked, we did not have the patch to allow -fuse-ld in >> gcc-4.6. >> >> There are other workarounds for this (e.g. add a custom flag to the >> sysroot wrapper). We need to discuss what the best approach is for >> specifying custom linkers. >> >> Raymes >> >> On Mon, Sep 5, 2011 at 5:57 PM, Bhaskar Janakiraman >> <bjanakiraman@google.com> wrote: >> > Can you use -fuse-ld=ld-bfd option to force use of ld.bfd, or does this >> > not >> > help? >> > Bhaskar >> > >> > On Mon, Sep 5, 2011 at 10:42 AM, <raymes@chromium.org> wrote: >> >> >> >> The problem is that the chrome ebuild also uses the -B flag to select >> >> gold. >> >> >> >> Since the host-built cross-compiler knows nothing about this new ld_bfd >> >> linker, >> >> does it make more sense to invoke the linker directly rather than >> >> through >> >> the >> >> gcc driver? Or is there a nacl gcc driver that should be used to invoke >> >> this >> >> linker? >> >> >> >> We need to look at the possibility of unifying the NaCl/ChromeOS >> >> toolchains in >> >> some way. >> >> >> >> http://codereview.chromium.org/7800026/ >> > >> > > > -- You received this message because you are subscribed to the Google Groups "Native-Client-Reviews" group. To post to this group, send email to native-client-reviews@googlegroups.com. To unsubscribe from this group, send email to native-client-reviews+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/native-client-reviews?hl=en.
Hi Brad, I discussed this with Bhaskar and we decided that -fuse-ld is the best option here and we will support this going forward. This will allow you to select gold/bfd from the gyp. The usage is: $CC -fuse-ld=bfd ... #(for GNU ld) $CC -fuse-ld=gold ... #(for gold) Can you try adding this flag to your build? This should work even when combined with the -B option that we currently pass in. Note that this flag is a local patch that we have in the compiler, it hasn't yet been accepted upstream. But we plan to support this going forward (and hopefully try to get it upstream) as a useful way of switching linkers. Keep in mind that when compiling outside of the ChromeOS environment, that flag might not be available. Let me know if you have any problems with this. Thanks, Raymes On Mon, Sep 5, 2011 at 11:35 PM, Raymes Khoury <raymes@chromium.org> wrote: > Thanks for the clarification! > >> Background: This doesn't have anything to do with the nacl tools. We are >> using ld.bfd to build a Linux executable with a slightly tweaked memory >> layout, needed to properly initialize the address space on Chrome OS. We >> need to use the BFD loader because current releases of gold don't implement >> the -T flag properly. Although Ian Taylor has fixed that bug for us, I don't >> expect the fix has made it into a binutils release yet. > > I see and I just took a look at the ld_bfd wrapper script > (http://src.chromium.org/viewvc/chrome/trunk/src/tools/ld_bfd/ld). > That wrapper script might fail for ChromeOS anyway, because our linker > is not installed in /usr/bin/ld. We have cross-compilers and they are > installed in /usr/bin/[target-arch]-ld. Even worse, it may appear to > work but use the host-linker instead of the cross-linker. > >> Thinking about this while traveling today, I don't understand why the Chrome >> OS build selects gold as it does using all the environment variables plus >> the -B flag. This seems much more complex and less robust than the common >> practice of a soft link from /usr/bin/ld to gold. With the common approach >> everything uses gold by default, but the BFD loader is still available as >> ld.bfd. Since you're building in a chroot environment the soft link from >> /usr/bin/ld seems that much more practical. >> Asking myself why you would do something different, I thought perhaps you >> wanted to avoid replacing /usr/bin/ld, so that the BFD loader would be >> available in that location. > > Yes, we do indeed create a soft-link as you say but the situation is > more complicated than that. For x86, the file > /usr/bin/i686-pc-linux-gnu-ld does indeed point to gold, as you > suggest. For ARM, however, it does not because GNU ld is still the > default for ARM (but we build chrome with gold). Also a handful of > other packages fail to build with gold so we need a way to use bfd. > This is why we use the -B flag in other ebuilds. Basically we face the > same problem as you, which is that the only supported way of switching > linkers is with -B and that isn't a very good mechanism (as shown > here). > >> Except what you have achieved instead is the >> opposite, making it effectively impossible to specify the BFD loader during >> a GYP build. > > Yes that is true, but this is a problem with the mechanism for > selecting a linker and has nothing to do with what the default linker > is. > >> It may be possible to specify a load commend in GYP however this is more GYP >> wizardry than I had at my disposal at the time. Given the way that GYP >> sometimes seems specific to what Chrome needs, it may be that this feature >> is not yet supported. This and your -fuse= suggestion I will look into first >> thing tomorrow morning. I'm not familiar with -fuse-ld, this is a recent gcc >> option? > > -fuse-ld does solve this problem but last time I checked, it was a > patch that was not comitted upstream (it was still pending). Moreover, > it had a bug in it. In any case, we can provide a solution to make it > easy to select ld.bfd in the gyp, if that's what you want to achieve > (at least for ChromeOS). I'll discuss with the toolchain team tomorrow > how we want to do this (whether it be to use fuse-ld or some other > mechanism). > > Another thing we may want to do is to backport the patch you need for > gold, which we can do relatively quickly, but this would only sidestep > the linker selection issue. > > Thanks, > Raymes > > > > On Mon, Sep 5, 2011 at 9:45 PM, Brad Chen <bradchen@google.com> wrote: >> Background: This doesn't have anything to do with the nacl tools. We are >> using ld.bfd to build a Linux executable with a slightly tweaked memory >> layout, needed to properly initialize the address space on Chrome OS. We >> need to use the BFD loader because current releases of gold don't implement >> the -T flag properly. Although Ian Taylor has fixed that bug for us, I don't >> expect the fix has made it into a binutils release yet. >> Thinking about this while traveling today, I don't understand why the Chrome >> OS build selects gold as it does using all the environment variables plus >> the -B flag. This seems much more complex and less robust than the common >> practice of a soft link from /usr/bin/ld to gold. With the common approach >> everything uses gold by default, but the BFD loader is still available as >> ld.bfd. Since you're building in a chroot environment the soft link from >> /usr/bin/ld seems that much more practical. >> Asking myself why you would do something different, I thought perhaps you >> wanted to avoid replacing /usr/bin/ld, so that the BFD loader would be >> available in that location. Except what you have achieved instead is the >> opposite, making it effectively impossible to specify the BFD loader during >> a GYP build. >> It may be possible to specify a load commend in GYP however this is more GYP >> wizardry than I had at my disposal at the time. Given the way that GYP >> sometimes seems specific to what Chrome needs, it may be that this feature >> is not yet supported. This and your -fuse= suggestion I will look into first >> thing tomorrow morning. I'm not familiar with -fuse-ld, this is a recent gcc >> option? >> Brad >> >> On Mon, Sep 5, 2011 at 6:39 PM, Raymes Khoury <raymes@chromium.org> wrote: >>> >>> -fuse-ld=bfd would allow us to work around the problem by changing the >>> chrome ebuild but there are problems with that approach as well. Last >>> time I checked, we did not have the patch to allow -fuse-ld in >>> gcc-4.6. >>> >>> There are other workarounds for this (e.g. add a custom flag to the >>> sysroot wrapper). We need to discuss what the best approach is for >>> specifying custom linkers. >>> >>> Raymes >>> >>> On Mon, Sep 5, 2011 at 5:57 PM, Bhaskar Janakiraman >>> <bjanakiraman@google.com> wrote: >>> > Can you use -fuse-ld=ld-bfd option to force use of ld.bfd, or does this >>> > not >>> > help? >>> > Bhaskar >>> > >>> > On Mon, Sep 5, 2011 at 10:42 AM, <raymes@chromium.org> wrote: >>> >> >>> >> The problem is that the chrome ebuild also uses the -B flag to select >>> >> gold. >>> >> >>> >> Since the host-built cross-compiler knows nothing about this new ld_bfd >>> >> linker, >>> >> does it make more sense to invoke the linker directly rather than >>> >> through >>> >> the >>> >> gcc driver? Or is there a nacl gcc driver that should be used to invoke >>> >> this >>> >> linker? >>> >> >>> >> We need to look at the possibility of unifying the NaCl/ChromeOS >>> >> toolchains in >>> >> some way. >>> >> >>> >> http://codereview.chromium.org/7800026/ >>> > >>> > >> >> > -- You received this message because you are subscribed to the Google Groups "Native-Client-Reviews" group. To post to this group, send email to native-client-reviews@googlegroups.com. To unsubscribe from this group, send email to native-client-reviews+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/native-client-reviews?hl=en.
Hi Brad, I discussed this with Bhaskar and we decided that -fuse-ld is the best option here and we will support this going forward. This will allow you to select gold/bfd from the gyp. The usage is: $CC -fuse-ld=bfd ... #(for GNU ld) $CC -fuse-ld=gold ... #(for gold) Can you try adding this flag to your build? This should work even when combined with the -B option that we currently pass in. Note that this flag is a local patch that we have in the compiler, it hasn't yet been accepted upstream. But we plan to support this going forward (and hopefully try to get it upstream) as a useful way of switching linkers. Keep in mind that when compiling outside of the ChromeOS environment, that flag might not be available. Let me know if you have any problems with this. Thanks, Raymes On Mon, Sep 5, 2011 at 11:35 PM, Raymes Khoury <raymes@chromium.org> wrote: > Thanks for the clarification! > >> Background: This doesn't have anything to do with the nacl tools. We are >> using ld.bfd to build a Linux executable with a slightly tweaked memory >> layout, needed to properly initialize the address space on Chrome OS. We >> need to use the BFD loader because current releases of gold don't implement >> the -T flag properly. Although Ian Taylor has fixed that bug for us, I don't >> expect the fix has made it into a binutils release yet. > > I see and I just took a look at the ld_bfd wrapper script > (http://src.chromium.org/viewvc/chrome/trunk/src/tools/ld_bfd/ld). > That wrapper script might fail for ChromeOS anyway, because our linker > is not installed in /usr/bin/ld. We have cross-compilers and they are > installed in /usr/bin/[target-arch]-ld. Even worse, it may appear to > work but use the host-linker instead of the cross-linker. > >> Thinking about this while traveling today, I don't understand why the Chrome >> OS build selects gold as it does using all the environment variables plus >> the -B flag. This seems much more complex and less robust than the common >> practice of a soft link from /usr/bin/ld to gold. With the common approach >> everything uses gold by default, but the BFD loader is still available as >> ld.bfd. Since you're building in a chroot environment the soft link from >> /usr/bin/ld seems that much more practical. >> Asking myself why you would do something different, I thought perhaps you >> wanted to avoid replacing /usr/bin/ld, so that the BFD loader would be >> available in that location. > > Yes, we do indeed create a soft-link as you say but the situation is > more complicated than that. For x86, the file > /usr/bin/i686-pc-linux-gnu-ld does indeed point to gold, as you > suggest. For ARM, however, it does not because GNU ld is still the > default for ARM (but we build chrome with gold). Also a handful of > other packages fail to build with gold so we need a way to use bfd. > This is why we use the -B flag in other ebuilds. Basically we face the > same problem as you, which is that the only supported way of switching > linkers is with -B and that isn't a very good mechanism (as shown > here). > >> Except what you have achieved instead is the >> opposite, making it effectively impossible to specify the BFD loader during >> a GYP build. > > Yes that is true, but this is a problem with the mechanism for > selecting a linker and has nothing to do with what the default linker > is. > >> It may be possible to specify a load commend in GYP however this is more GYP >> wizardry than I had at my disposal at the time. Given the way that GYP >> sometimes seems specific to what Chrome needs, it may be that this feature >> is not yet supported. This and your -fuse= suggestion I will look into first >> thing tomorrow morning. I'm not familiar with -fuse-ld, this is a recent gcc >> option? > > -fuse-ld does solve this problem but last time I checked, it was a > patch that was not comitted upstream (it was still pending). Moreover, > it had a bug in it. In any case, we can provide a solution to make it > easy to select ld.bfd in the gyp, if that's what you want to achieve > (at least for ChromeOS). I'll discuss with the toolchain team tomorrow > how we want to do this (whether it be to use fuse-ld or some other > mechanism). > > Another thing we may want to do is to backport the patch you need for > gold, which we can do relatively quickly, but this would only sidestep > the linker selection issue. > > Thanks, > Raymes > > > > On Mon, Sep 5, 2011 at 9:45 PM, Brad Chen <bradchen@google.com> wrote: >> Background: This doesn't have anything to do with the nacl tools. We are >> using ld.bfd to build a Linux executable with a slightly tweaked memory >> layout, needed to properly initialize the address space on Chrome OS. We >> need to use the BFD loader because current releases of gold don't implement >> the -T flag properly. Although Ian Taylor has fixed that bug for us, I don't >> expect the fix has made it into a binutils release yet. >> Thinking about this while traveling today, I don't understand why the Chrome >> OS build selects gold as it does using all the environment variables plus >> the -B flag. This seems much more complex and less robust than the common >> practice of a soft link from /usr/bin/ld to gold. With the common approach >> everything uses gold by default, but the BFD loader is still available as >> ld.bfd. Since you're building in a chroot environment the soft link from >> /usr/bin/ld seems that much more practical. >> Asking myself why you would do something different, I thought perhaps you >> wanted to avoid replacing /usr/bin/ld, so that the BFD loader would be >> available in that location. Except what you have achieved instead is the >> opposite, making it effectively impossible to specify the BFD loader during >> a GYP build. >> It may be possible to specify a load commend in GYP however this is more GYP >> wizardry than I had at my disposal at the time. Given the way that GYP >> sometimes seems specific to what Chrome needs, it may be that this feature >> is not yet supported. This and your -fuse= suggestion I will look into first >> thing tomorrow morning. I'm not familiar with -fuse-ld, this is a recent gcc >> option? >> Brad >> >> On Mon, Sep 5, 2011 at 6:39 PM, Raymes Khoury <raymes@chromium.org> wrote: >>> >>> -fuse-ld=bfd would allow us to work around the problem by changing the >>> chrome ebuild but there are problems with that approach as well. Last >>> time I checked, we did not have the patch to allow -fuse-ld in >>> gcc-4.6. >>> >>> There are other workarounds for this (e.g. add a custom flag to the >>> sysroot wrapper). We need to discuss what the best approach is for >>> specifying custom linkers. >>> >>> Raymes >>> >>> On Mon, Sep 5, 2011 at 5:57 PM, Bhaskar Janakiraman >>> <bjanakiraman@google.com> wrote: >>> > Can you use -fuse-ld=ld-bfd option to force use of ld.bfd, or does this >>> > not >>> > help? >>> > Bhaskar >>> > >>> > On Mon, Sep 5, 2011 at 10:42 AM, <raymes@chromium.org> wrote: >>> >> >>> >> The problem is that the chrome ebuild also uses the -B flag to select >>> >> gold. >>> >> >>> >> Since the host-built cross-compiler knows nothing about this new ld_bfd >>> >> linker, >>> >> does it make more sense to invoke the linker directly rather than >>> >> through >>> >> the >>> >> gcc driver? Or is there a nacl gcc driver that should be used to invoke >>> >> this >>> >> linker? >>> >> >>> >> We need to look at the possibility of unifying the NaCl/ChromeOS >>> >> toolchains in >>> >> some way. >>> >> >>> >> http://codereview.chromium.org/7800026/ >>> > >>> > >> >> >
I'm working with Raymes on testing and committing this. On Tue, Sep 6, 2011 at 10:02 AM, Raymes Khoury <raymes@chromium.org> wrote: > Hi Brad, > > I discussed this with Bhaskar and we decided that -fuse-ld is the best > option here and we will support this going forward. This will allow > you to select gold/bfd from the gyp. > > The usage is: > $CC -fuse-ld=bfd ... #(for GNU ld) > $CC -fuse-ld=gold ... #(for gold) > > Can you try adding this flag to your build? This should work even when > combined with the -B option that we currently pass in. > > Note that this flag is a local patch that we have in the compiler, it > hasn't yet been accepted upstream. But we plan to support this going > forward (and hopefully try to get it upstream) as a useful way of > switching linkers. Keep in mind that when compiling outside of the > ChromeOS environment, that flag might not be available. > > Let me know if you have any problems with this. > > Thanks, > Raymes > > On Mon, Sep 5, 2011 at 11:35 PM, Raymes Khoury <raymes@chromium.org> > wrote: > > Thanks for the clarification! > > > >> Background: This doesn't have anything to do with the nacl tools. We are > >> using ld.bfd to build a Linux executable with a slightly tweaked memory > >> layout, needed to properly initialize the address space on Chrome OS. We > >> need to use the BFD loader because current releases of gold don't > implement > >> the -T flag properly. Although Ian Taylor has fixed that bug for us, I > don't > >> expect the fix has made it into a binutils release yet. > > > > I see and I just took a look at the ld_bfd wrapper script > > (http://src.chromium.org/viewvc/chrome/trunk/src/tools/ld_bfd/ld). > > That wrapper script might fail for ChromeOS anyway, because our linker > > is not installed in /usr/bin/ld. We have cross-compilers and they are > > installed in /usr/bin/[target-arch]-ld. Even worse, it may appear to > > work but use the host-linker instead of the cross-linker. > > > >> Thinking about this while traveling today, I don't understand why the > Chrome > >> OS build selects gold as it does using all the environment variables > plus > >> the -B flag. This seems much more complex and less robust than the > common > >> practice of a soft link from /usr/bin/ld to gold. With the common > approach > >> everything uses gold by default, but the BFD loader is still available > as > >> ld.bfd. Since you're building in a chroot environment the soft link from > >> /usr/bin/ld seems that much more practical. > >> Asking myself why you would do something different, I thought perhaps > you > >> wanted to avoid replacing /usr/bin/ld, so that the BFD loader would be > >> available in that location. > > > > Yes, we do indeed create a soft-link as you say but the situation is > > more complicated than that. For x86, the file > > /usr/bin/i686-pc-linux-gnu-ld does indeed point to gold, as you > > suggest. For ARM, however, it does not because GNU ld is still the > > default for ARM (but we build chrome with gold). Also a handful of > > other packages fail to build with gold so we need a way to use bfd. > > This is why we use the -B flag in other ebuilds. Basically we face the > > same problem as you, which is that the only supported way of switching > > linkers is with -B and that isn't a very good mechanism (as shown > > here). > > > >> Except what you have achieved instead is the > >> opposite, making it effectively impossible to specify the BFD loader > during > >> a GYP build. > > > > Yes that is true, but this is a problem with the mechanism for > > selecting a linker and has nothing to do with what the default linker > > is. > > > >> It may be possible to specify a load commend in GYP however this is more > GYP > >> wizardry than I had at my disposal at the time. Given the way that GYP > >> sometimes seems specific to what Chrome needs, it may be that this > feature > >> is not yet supported. This and your -fuse= suggestion I will look into > first > >> thing tomorrow morning. I'm not familiar with -fuse-ld, this is a recent > gcc > >> option? > > > > -fuse-ld does solve this problem but last time I checked, it was a > > patch that was not comitted upstream (it was still pending). Moreover, > > it had a bug in it. In any case, we can provide a solution to make it > > easy to select ld.bfd in the gyp, if that's what you want to achieve > > (at least for ChromeOS). I'll discuss with the toolchain team tomorrow > > how we want to do this (whether it be to use fuse-ld or some other > > mechanism). > > > > Another thing we may want to do is to backport the patch you need for > > gold, which we can do relatively quickly, but this would only sidestep > > the linker selection issue. > > > > Thanks, > > Raymes > > > > > > > > On Mon, Sep 5, 2011 at 9:45 PM, Brad Chen <bradchen@google.com> wrote: > >> Background: This doesn't have anything to do with the nacl tools. We are > >> using ld.bfd to build a Linux executable with a slightly tweaked memory > >> layout, needed to properly initialize the address space on Chrome OS. We > >> need to use the BFD loader because current releases of gold don't > implement > >> the -T flag properly. Although Ian Taylor has fixed that bug for us, I > don't > >> expect the fix has made it into a binutils release yet. > >> Thinking about this while traveling today, I don't understand why the > Chrome > >> OS build selects gold as it does using all the environment variables > plus > >> the -B flag. This seems much more complex and less robust than the > common > >> practice of a soft link from /usr/bin/ld to gold. With the common > approach > >> everything uses gold by default, but the BFD loader is still available > as > >> ld.bfd. Since you're building in a chroot environment the soft link from > >> /usr/bin/ld seems that much more practical. > >> Asking myself why you would do something different, I thought perhaps > you > >> wanted to avoid replacing /usr/bin/ld, so that the BFD loader would be > >> available in that location. Except what you have achieved instead is the > >> opposite, making it effectively impossible to specify the BFD loader > during > >> a GYP build. > >> It may be possible to specify a load commend in GYP however this is more > GYP > >> wizardry than I had at my disposal at the time. Given the way that GYP > >> sometimes seems specific to what Chrome needs, it may be that this > feature > >> is not yet supported. This and your -fuse= suggestion I will look into > first > >> thing tomorrow morning. I'm not familiar with -fuse-ld, this is a recent > gcc > >> option? > >> Brad > >> > >> On Mon, Sep 5, 2011 at 6:39 PM, Raymes Khoury <raymes@chromium.org> > wrote: > >>> > >>> -fuse-ld=bfd would allow us to work around the problem by changing the > >>> chrome ebuild but there are problems with that approach as well. Last > >>> time I checked, we did not have the patch to allow -fuse-ld in > >>> gcc-4.6. > >>> > >>> There are other workarounds for this (e.g. add a custom flag to the > >>> sysroot wrapper). We need to discuss what the best approach is for > >>> specifying custom linkers. > >>> > >>> Raymes > >>> > >>> On Mon, Sep 5, 2011 at 5:57 PM, Bhaskar Janakiraman > >>> <bjanakiraman@google.com> wrote: > >>> > Can you use -fuse-ld=ld-bfd option to force use of ld.bfd, or does > this > >>> > not > >>> > help? > >>> > Bhaskar > >>> > > >>> > On Mon, Sep 5, 2011 at 10:42 AM, <raymes@chromium.org> wrote: > >>> >> > >>> >> The problem is that the chrome ebuild also uses the -B flag to > select > >>> >> gold. > >>> >> > >>> >> Since the host-built cross-compiler knows nothing about this new > ld_bfd > >>> >> linker, > >>> >> does it make more sense to invoke the linker directly rather than > >>> >> through > >>> >> the > >>> >> gcc driver? Or is there a nacl gcc driver that should be used to > invoke > >>> >> this > >>> >> linker? > >>> >> > >>> >> We need to look at the possibility of unifying the NaCl/ChromeOS > >>> >> toolchains in > >>> >> some way. > >>> >> > >>> >> http://codereview.chromium.org/7800026/ > >>> > > >>> > > >> > >> > > > -- You received this message because you are subscribed to the Google Groups "Native-Client-Reviews" group. To post to this group, send email to native-client-reviews@googlegroups.com. To unsubscribe from this group, send email to native-client-reviews+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/native-client-reviews?hl=en.
I'm working with Raymes on testing and committing this. On Tue, Sep 6, 2011 at 10:02 AM, Raymes Khoury <raymes@chromium.org> wrote: > Hi Brad, > > I discussed this with Bhaskar and we decided that -fuse-ld is the best > option here and we will support this going forward. This will allow > you to select gold/bfd from the gyp. > > The usage is: > $CC -fuse-ld=bfd ... #(for GNU ld) > $CC -fuse-ld=gold ... #(for gold) > > Can you try adding this flag to your build? This should work even when > combined with the -B option that we currently pass in. > > Note that this flag is a local patch that we have in the compiler, it > hasn't yet been accepted upstream. But we plan to support this going > forward (and hopefully try to get it upstream) as a useful way of > switching linkers. Keep in mind that when compiling outside of the > ChromeOS environment, that flag might not be available. > > Let me know if you have any problems with this. > > Thanks, > Raymes > > On Mon, Sep 5, 2011 at 11:35 PM, Raymes Khoury <raymes@chromium.org> > wrote: > > Thanks for the clarification! > > > >> Background: This doesn't have anything to do with the nacl tools. We are > >> using ld.bfd to build a Linux executable with a slightly tweaked memory > >> layout, needed to properly initialize the address space on Chrome OS. We > >> need to use the BFD loader because current releases of gold don't > implement > >> the -T flag properly. Although Ian Taylor has fixed that bug for us, I > don't > >> expect the fix has made it into a binutils release yet. > > > > I see and I just took a look at the ld_bfd wrapper script > > (http://src.chromium.org/viewvc/chrome/trunk/src/tools/ld_bfd/ld). > > That wrapper script might fail for ChromeOS anyway, because our linker > > is not installed in /usr/bin/ld. We have cross-compilers and they are > > installed in /usr/bin/[target-arch]-ld. Even worse, it may appear to > > work but use the host-linker instead of the cross-linker. > > > >> Thinking about this while traveling today, I don't understand why the > Chrome > >> OS build selects gold as it does using all the environment variables > plus > >> the -B flag. This seems much more complex and less robust than the > common > >> practice of a soft link from /usr/bin/ld to gold. With the common > approach > >> everything uses gold by default, but the BFD loader is still available > as > >> ld.bfd. Since you're building in a chroot environment the soft link from > >> /usr/bin/ld seems that much more practical. > >> Asking myself why you would do something different, I thought perhaps > you > >> wanted to avoid replacing /usr/bin/ld, so that the BFD loader would be > >> available in that location. > > > > Yes, we do indeed create a soft-link as you say but the situation is > > more complicated than that. For x86, the file > > /usr/bin/i686-pc-linux-gnu-ld does indeed point to gold, as you > > suggest. For ARM, however, it does not because GNU ld is still the > > default for ARM (but we build chrome with gold). Also a handful of > > other packages fail to build with gold so we need a way to use bfd. > > This is why we use the -B flag in other ebuilds. Basically we face the > > same problem as you, which is that the only supported way of switching > > linkers is with -B and that isn't a very good mechanism (as shown > > here). > > > >> Except what you have achieved instead is the > >> opposite, making it effectively impossible to specify the BFD loader > during > >> a GYP build. > > > > Yes that is true, but this is a problem with the mechanism for > > selecting a linker and has nothing to do with what the default linker > > is. > > > >> It may be possible to specify a load commend in GYP however this is more > GYP > >> wizardry than I had at my disposal at the time. Given the way that GYP > >> sometimes seems specific to what Chrome needs, it may be that this > feature > >> is not yet supported. This and your -fuse= suggestion I will look into > first > >> thing tomorrow morning. I'm not familiar with -fuse-ld, this is a recent > gcc > >> option? > > > > -fuse-ld does solve this problem but last time I checked, it was a > > patch that was not comitted upstream (it was still pending). Moreover, > > it had a bug in it. In any case, we can provide a solution to make it > > easy to select ld.bfd in the gyp, if that's what you want to achieve > > (at least for ChromeOS). I'll discuss with the toolchain team tomorrow > > how we want to do this (whether it be to use fuse-ld or some other > > mechanism). > > > > Another thing we may want to do is to backport the patch you need for > > gold, which we can do relatively quickly, but this would only sidestep > > the linker selection issue. > > > > Thanks, > > Raymes > > > > > > > > On Mon, Sep 5, 2011 at 9:45 PM, Brad Chen <bradchen@google.com> wrote: > >> Background: This doesn't have anything to do with the nacl tools. We are > >> using ld.bfd to build a Linux executable with a slightly tweaked memory > >> layout, needed to properly initialize the address space on Chrome OS. We > >> need to use the BFD loader because current releases of gold don't > implement > >> the -T flag properly. Although Ian Taylor has fixed that bug for us, I > don't > >> expect the fix has made it into a binutils release yet. > >> Thinking about this while traveling today, I don't understand why the > Chrome > >> OS build selects gold as it does using all the environment variables > plus > >> the -B flag. This seems much more complex and less robust than the > common > >> practice of a soft link from /usr/bin/ld to gold. With the common > approach > >> everything uses gold by default, but the BFD loader is still available > as > >> ld.bfd. Since you're building in a chroot environment the soft link from > >> /usr/bin/ld seems that much more practical. > >> Asking myself why you would do something different, I thought perhaps > you > >> wanted to avoid replacing /usr/bin/ld, so that the BFD loader would be > >> available in that location. Except what you have achieved instead is the > >> opposite, making it effectively impossible to specify the BFD loader > during > >> a GYP build. > >> It may be possible to specify a load commend in GYP however this is more > GYP > >> wizardry than I had at my disposal at the time. Given the way that GYP > >> sometimes seems specific to what Chrome needs, it may be that this > feature > >> is not yet supported. This and your -fuse= suggestion I will look into > first > >> thing tomorrow morning. I'm not familiar with -fuse-ld, this is a recent > gcc > >> option? > >> Brad > >> > >> On Mon, Sep 5, 2011 at 6:39 PM, Raymes Khoury <raymes@chromium.org> > wrote: > >>> > >>> -fuse-ld=bfd would allow us to work around the problem by changing the > >>> chrome ebuild but there are problems with that approach as well. Last > >>> time I checked, we did not have the patch to allow -fuse-ld in > >>> gcc-4.6. > >>> > >>> There are other workarounds for this (e.g. add a custom flag to the > >>> sysroot wrapper). We need to discuss what the best approach is for > >>> specifying custom linkers. > >>> > >>> Raymes > >>> > >>> On Mon, Sep 5, 2011 at 5:57 PM, Bhaskar Janakiraman > >>> <bjanakiraman@google.com> wrote: > >>> > Can you use -fuse-ld=ld-bfd option to force use of ld.bfd, or does > this > >>> > not > >>> > help? > >>> > Bhaskar > >>> > > >>> > On Mon, Sep 5, 2011 at 10:42 AM, <raymes@chromium.org> wrote: > >>> >> > >>> >> The problem is that the chrome ebuild also uses the -B flag to > select > >>> >> gold. > >>> >> > >>> >> Since the host-built cross-compiler knows nothing about this new > ld_bfd > >>> >> linker, > >>> >> does it make more sense to invoke the linker directly rather than > >>> >> through > >>> >> the > >>> >> gcc driver? Or is there a nacl gcc driver that should be used to > invoke > >>> >> this > >>> >> linker? > >>> >> > >>> >> We need to look at the possibility of unifying the NaCl/ChromeOS > >>> >> toolchains in > >>> >> some way. > >>> >> > >>> >> http://codereview.chromium.org/7800026/ > >>> > > >>> > > >> > >> > > >
BTW The Gold patch is linked here: http://sourceware.org/ml/binutils/2011-07/msg00206.html I'm checking with Ian on when it should make it into a binutils release. Brad On Mon, Sep 5, 2011 at 11:35 PM, Raymes Khoury <raymes@chromium.org> wrote: > Thanks for the clarification! > > > Background: This doesn't have anything to do with the nacl tools. We are > > using ld.bfd to build a Linux executable with a slightly tweaked memory > > layout, needed to properly initialize the address space on Chrome OS. We > > need to use the BFD loader because current releases of gold don't > implement > > the -T flag properly. Although Ian Taylor has fixed that bug for us, I > don't > > expect the fix has made it into a binutils release yet. > > I see and I just took a look at the ld_bfd wrapper script > (http://src.chromium.org/viewvc/chrome/trunk/src/tools/ld_bfd/ld). > That wrapper script might fail for ChromeOS anyway, because our linker > is not installed in /usr/bin/ld. We have cross-compilers and they are > installed in /usr/bin/[target-arch]-ld. Even worse, it may appear to > work but use the host-linker instead of the cross-linker. > > > Thinking about this while traveling today, I don't understand why the > Chrome > > OS build selects gold as it does using all the environment variables plus > > the -B flag. This seems much more complex and less robust than the common > > practice of a soft link from /usr/bin/ld to gold. With the common > approach > > everything uses gold by default, but the BFD loader is still available as > > ld.bfd. Since you're building in a chroot environment the soft link from > > /usr/bin/ld seems that much more practical. > > Asking myself why you would do something different, I thought perhaps you > > wanted to avoid replacing /usr/bin/ld, so that the BFD loader would be > > available in that location. > > Yes, we do indeed create a soft-link as you say but the situation is > more complicated than that. For x86, the file > /usr/bin/i686-pc-linux-gnu-ld does indeed point to gold, as you > suggest. For ARM, however, it does not because GNU ld is still the > default for ARM (but we build chrome with gold). Also a handful of > other packages fail to build with gold so we need a way to use bfd. > This is why we use the -B flag in other ebuilds. Basically we face the > same problem as you, which is that the only supported way of switching > linkers is with -B and that isn't a very good mechanism (as shown > here). > > > Except what you have achieved instead is the > > opposite, making it effectively impossible to specify the BFD loader > during > > a GYP build. > > Yes that is true, but this is a problem with the mechanism for > selecting a linker and has nothing to do with what the default linker > is. > > > It may be possible to specify a load commend in GYP however this is more > GYP > > wizardry than I had at my disposal at the time. Given the way that GYP > > sometimes seems specific to what Chrome needs, it may be that this > feature > > is not yet supported. This and your -fuse= suggestion I will look into > first > > thing tomorrow morning. I'm not familiar with -fuse-ld, this is a recent > gcc > > option? > > -fuse-ld does solve this problem but last time I checked, it was a > patch that was not comitted upstream (it was still pending). Moreover, > it had a bug in it. In any case, we can provide a solution to make it > easy to select ld.bfd in the gyp, if that's what you want to achieve > (at least for ChromeOS). I'll discuss with the toolchain team tomorrow > how we want to do this (whether it be to use fuse-ld or some other > mechanism). > > Another thing we may want to do is to backport the patch you need for > gold, which we can do relatively quickly, but this would only sidestep > the linker selection issue. > > Thanks, > Raymes > > > > On Mon, Sep 5, 2011 at 9:45 PM, Brad Chen <bradchen@google.com> wrote: > > Background: This doesn't have anything to do with the nacl tools. We are > > using ld.bfd to build a Linux executable with a slightly tweaked memory > > layout, needed to properly initialize the address space on Chrome OS. We > > need to use the BFD loader because current releases of gold don't > implement > > the -T flag properly. Although Ian Taylor has fixed that bug for us, I > don't > > expect the fix has made it into a binutils release yet. > > Thinking about this while traveling today, I don't understand why the > Chrome > > OS build selects gold as it does using all the environment variables plus > > the -B flag. This seems much more complex and less robust than the common > > practice of a soft link from /usr/bin/ld to gold. With the common > approach > > everything uses gold by default, but the BFD loader is still available as > > ld.bfd. Since you're building in a chroot environment the soft link from > > /usr/bin/ld seems that much more practical. > > Asking myself why you would do something different, I thought perhaps you > > wanted to avoid replacing /usr/bin/ld, so that the BFD loader would be > > available in that location. Except what you have achieved instead is the > > opposite, making it effectively impossible to specify the BFD loader > during > > a GYP build. > > It may be possible to specify a load commend in GYP however this is more > GYP > > wizardry than I had at my disposal at the time. Given the way that GYP > > sometimes seems specific to what Chrome needs, it may be that this > feature > > is not yet supported. This and your -fuse= suggestion I will look into > first > > thing tomorrow morning. I'm not familiar with -fuse-ld, this is a recent > gcc > > option? > > Brad > > > > On Mon, Sep 5, 2011 at 6:39 PM, Raymes Khoury <raymes@chromium.org> > wrote: > >> > >> -fuse-ld=bfd would allow us to work around the problem by changing the > >> chrome ebuild but there are problems with that approach as well. Last > >> time I checked, we did not have the patch to allow -fuse-ld in > >> gcc-4.6. > >> > >> There are other workarounds for this (e.g. add a custom flag to the > >> sysroot wrapper). We need to discuss what the best approach is for > >> specifying custom linkers. > >> > >> Raymes > >> > >> On Mon, Sep 5, 2011 at 5:57 PM, Bhaskar Janakiraman > >> <bjanakiraman@google.com> wrote: > >> > Can you use -fuse-ld=ld-bfd option to force use of ld.bfd, or does > this > >> > not > >> > help? > >> > Bhaskar > >> > > >> > On Mon, Sep 5, 2011 at 10:42 AM, <raymes@chromium.org> wrote: > >> >> > >> >> The problem is that the chrome ebuild also uses the -B flag to select > >> >> gold. > >> >> > >> >> Since the host-built cross-compiler knows nothing about this new > ld_bfd > >> >> linker, > >> >> does it make more sense to invoke the linker directly rather than > >> >> through > >> >> the > >> >> gcc driver? Or is there a nacl gcc driver that should be used to > invoke > >> >> this > >> >> linker? > >> >> > >> >> We need to look at the possibility of unifying the NaCl/ChromeOS > >> >> toolchains in > >> >> some way. > >> >> > >> >> http://codereview.chromium.org/7800026/ > >> > > >> > > > > > > -- You received this message because you are subscribed to the Google Groups "Native-Client-Reviews" group. To post to this group, send email to native-client-reviews@googlegroups.com. To unsubscribe from this group, send email to native-client-reviews+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/native-client-reviews?hl=en.
BTW The Gold patch is linked here: http://sourceware.org/ml/binutils/2011-07/msg00206.html I'm checking with Ian on when it should make it into a binutils release. Brad On Mon, Sep 5, 2011 at 11:35 PM, Raymes Khoury <raymes@chromium.org> wrote: > Thanks for the clarification! > > > Background: This doesn't have anything to do with the nacl tools. We are > > using ld.bfd to build a Linux executable with a slightly tweaked memory > > layout, needed to properly initialize the address space on Chrome OS. We > > need to use the BFD loader because current releases of gold don't > implement > > the -T flag properly. Although Ian Taylor has fixed that bug for us, I > don't > > expect the fix has made it into a binutils release yet. > > I see and I just took a look at the ld_bfd wrapper script > (http://src.chromium.org/viewvc/chrome/trunk/src/tools/ld_bfd/ld). > That wrapper script might fail for ChromeOS anyway, because our linker > is not installed in /usr/bin/ld. We have cross-compilers and they are > installed in /usr/bin/[target-arch]-ld. Even worse, it may appear to > work but use the host-linker instead of the cross-linker. > > > Thinking about this while traveling today, I don't understand why the > Chrome > > OS build selects gold as it does using all the environment variables plus > > the -B flag. This seems much more complex and less robust than the common > > practice of a soft link from /usr/bin/ld to gold. With the common > approach > > everything uses gold by default, but the BFD loader is still available as > > ld.bfd. Since you're building in a chroot environment the soft link from > > /usr/bin/ld seems that much more practical. > > Asking myself why you would do something different, I thought perhaps you > > wanted to avoid replacing /usr/bin/ld, so that the BFD loader would be > > available in that location. > > Yes, we do indeed create a soft-link as you say but the situation is > more complicated than that. For x86, the file > /usr/bin/i686-pc-linux-gnu-ld does indeed point to gold, as you > suggest. For ARM, however, it does not because GNU ld is still the > default for ARM (but we build chrome with gold). Also a handful of > other packages fail to build with gold so we need a way to use bfd. > This is why we use the -B flag in other ebuilds. Basically we face the > same problem as you, which is that the only supported way of switching > linkers is with -B and that isn't a very good mechanism (as shown > here). > > > Except what you have achieved instead is the > > opposite, making it effectively impossible to specify the BFD loader > during > > a GYP build. > > Yes that is true, but this is a problem with the mechanism for > selecting a linker and has nothing to do with what the default linker > is. > > > It may be possible to specify a load commend in GYP however this is more > GYP > > wizardry than I had at my disposal at the time. Given the way that GYP > > sometimes seems specific to what Chrome needs, it may be that this > feature > > is not yet supported. This and your -fuse= suggestion I will look into > first > > thing tomorrow morning. I'm not familiar with -fuse-ld, this is a recent > gcc > > option? > > -fuse-ld does solve this problem but last time I checked, it was a > patch that was not comitted upstream (it was still pending). Moreover, > it had a bug in it. In any case, we can provide a solution to make it > easy to select ld.bfd in the gyp, if that's what you want to achieve > (at least for ChromeOS). I'll discuss with the toolchain team tomorrow > how we want to do this (whether it be to use fuse-ld or some other > mechanism). > > Another thing we may want to do is to backport the patch you need for > gold, which we can do relatively quickly, but this would only sidestep > the linker selection issue. > > Thanks, > Raymes > > > > On Mon, Sep 5, 2011 at 9:45 PM, Brad Chen <bradchen@google.com> wrote: > > Background: This doesn't have anything to do with the nacl tools. We are > > using ld.bfd to build a Linux executable with a slightly tweaked memory > > layout, needed to properly initialize the address space on Chrome OS. We > > need to use the BFD loader because current releases of gold don't > implement > > the -T flag properly. Although Ian Taylor has fixed that bug for us, I > don't > > expect the fix has made it into a binutils release yet. > > Thinking about this while traveling today, I don't understand why the > Chrome > > OS build selects gold as it does using all the environment variables plus > > the -B flag. This seems much more complex and less robust than the common > > practice of a soft link from /usr/bin/ld to gold. With the common > approach > > everything uses gold by default, but the BFD loader is still available as > > ld.bfd. Since you're building in a chroot environment the soft link from > > /usr/bin/ld seems that much more practical. > > Asking myself why you would do something different, I thought perhaps you > > wanted to avoid replacing /usr/bin/ld, so that the BFD loader would be > > available in that location. Except what you have achieved instead is the > > opposite, making it effectively impossible to specify the BFD loader > during > > a GYP build. > > It may be possible to specify a load commend in GYP however this is more > GYP > > wizardry than I had at my disposal at the time. Given the way that GYP > > sometimes seems specific to what Chrome needs, it may be that this > feature > > is not yet supported. This and your -fuse= suggestion I will look into > first > > thing tomorrow morning. I'm not familiar with -fuse-ld, this is a recent > gcc > > option? > > Brad > > > > On Mon, Sep 5, 2011 at 6:39 PM, Raymes Khoury <raymes@chromium.org> > wrote: > >> > >> -fuse-ld=bfd would allow us to work around the problem by changing the > >> chrome ebuild but there are problems with that approach as well. Last > >> time I checked, we did not have the patch to allow -fuse-ld in > >> gcc-4.6. > >> > >> There are other workarounds for this (e.g. add a custom flag to the > >> sysroot wrapper). We need to discuss what the best approach is for > >> specifying custom linkers. > >> > >> Raymes > >> > >> On Mon, Sep 5, 2011 at 5:57 PM, Bhaskar Janakiraman > >> <bjanakiraman@google.com> wrote: > >> > Can you use -fuse-ld=ld-bfd option to force use of ld.bfd, or does > this > >> > not > >> > help? > >> > Bhaskar > >> > > >> > On Mon, Sep 5, 2011 at 10:42 AM, <raymes@chromium.org> wrote: > >> >> > >> >> The problem is that the chrome ebuild also uses the -B flag to select > >> >> gold. > >> >> > >> >> Since the host-built cross-compiler knows nothing about this new > ld_bfd > >> >> linker, > >> >> does it make more sense to invoke the linker directly rather than > >> >> through > >> >> the > >> >> gcc driver? Or is there a nacl gcc driver that should be used to > invoke > >> >> this > >> >> linker? > >> >> > >> >> We need to look at the possibility of unifying the NaCl/ChromeOS > >> >> toolchains in > >> >> some way. > >> >> > >> >> http://codereview.chromium.org/7800026/ > >> > > >> > > > > > > |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
