On Mon, Mar 22, 2010 at 12:08 PM, Doug Semler <dougsem...@gmail.com> wrote:
> On Mon, Mar 22, 2010 at 11:32 AM, Kai Tietz <ktiet...@googlemail.com> wrote:
>> Hello,
>>
>> I prepared a patch which supports underscoring option for ld for
>> x64/x86 pe-coff targets. I post it first here, so that possibly Doug
>> could comment on it.
>>
>> I have to add for it some additional test-cases in testsuite before
>> posting it upstream.
>>
>
> I'll look at it more closely after lunch in comparison to what I did
> (actually dig out my notes) but right now after a quick glance it
> seems to me that I also had to play with pe_details_type->underscored
> on the x86_64 target in ld/pe-dll.c to generate exports and imports
> correctly... But that may be because i also turned off underscoring
> by default when building in bfd/config.bfd, bfd/pe-x86_64.c and
> bfd/pei-x86_64.c (i.e. targ_underscore=no in config.bfd, and #define
> TARGET_UNDERSCORE 0 in the .c files) using a configure option.
Never mind...I looked at it more carefully after I ate and see that it
was done (I only saw the changes in the .em files when I first looked)
:)
Anyway a couple things:
Maybe include a configure option to default the toolchain
(--disable-leading-underscores in bfd/configure - be consistent :))?
This could modify the config.bfd and pe[i]-x86_64.c to correctly
default TARGET_UNDERSCORE. The mingw portion really doesn't need it
since it is built by dlltool compiled .o files directly (and not
linked, which is where this is really needed), but it would be nice to
have :)
Caveats that I see (not really on the binutils side but still there
nonetheless):
1) When using a default no underscore toolchain, GCC must have
CFLAGS_FOR_TARGET="-fno-leading-underscore" on the x64 build of the
target libraries during its build (i.e. make all-target-lib*), so that
it generates the correct code. Or it needs to be defaulted to no
underscore. When I first looked at this, I thought I could define
USER_LABEL_PREFIX to check at runtime (instead of "_" or "", define it
to something like ((TARGET_64BIT) && ix86_abi==MSABI) ? "" : "_").
But it turns out that collect2 uses this define as well and needs it
to not access those arch specific areas. So defining
USER_LABEL_PREFIX that way really doesn't work in a multilib build
without some hacking of the defines if the leading underscores are
different for the two arch's. If it's not a multilib build, then it's
easy since you can switch on !defined (TARGET_BI_ARCH) and use
TARGET_64BIT_DEFAULT to figure out what arch you are using. The hack
to collect2 to get the correct behavior is ugly, by the way :)
2) If you don't configure binutils to default to no underscore in the
target vector, GCC also needs to pass --no-leading-underscores to the
linker, either via -Wl,--no-leading-underscores passed (e.g. again in
CFLAGS_FOR_TARGET) or by having its linker spec modified so that it is
passed during the link phase if -fno-leading-underscore is passed.
Not sure whether that second one is really a good idea, but we are
talking about this specific toolchain.
3) The link spec needs to be modified anyway if no-leading-underscore
is being used, because right now gcc passes the explicit
_dllmaincrtstar...@12 during a DLL link, which doesn't exist in the
non-underscored mingw startups (built with configure
--disable-leading-underscores)...so you need something like (say for a
defaulted no leading underscore toolchain - done this way so that you
could potentially configure GCC differently depending on whether
binutils is defaulted to no underscore)
%{shared: %{mdll: %eshared and mdll are not compatible}} \
%{shared: --shared} %{mdll:--dll} \
%{static:-Bstatic} %{!static:-Bdynamic} \
- %{shared|mdll: -e _dllmaincrtstar...@12 --enable-auto-image-base} \
+ " ENTRY_LINK_SPEC " \
%(shared_libgcc_undefs)"
+#define ENTRY_LINK_SPEC "%{shared|mdll: --enable-auto-image-base \
+ %{" SPEC_64 ":-e DllMainCRTStartup} \
+ %{" SPEC_32 ":-e _dllmaincrtstar...@12}}"
Regardless of the changes made to GCC, if you don't default the target
in binutils to use it, anything that tries to use a no-underscored
mingw32 will need to remember to run gcc -fno-leading-underscore and
also somehow have the -Wl,--no-leading-underscore link option, which
is really why I like the idea of being able to completely default the
entire toolchain one way or the other (i.e. the same configure flag
that can turn it on and off in binutils, mingw, and gcc). Of course,
defaulting the toolchain to no leading underscores means rebuilding
and requiring the correct toolchain all the way across the board,
since it would be pretty much be breaking the ABI...
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
