2010/3/22 Doug Semler <[email protected]>:
> On Mon, Mar 22, 2010 at 12:08 PM, Doug Semler <[email protected]> wrote:
>> On Mon, Mar 22, 2010 at 11:32 AM, Kai Tietz <[email protected]> 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)
> :)
Ah, ok. I was curious .)
> Anyway a couple things:
> Maybe include a configure option to default the toolchain
> (--disable-leading-underscores in bfd/configure - be consistent :))?
Yes, this is my point here, too. I want to eliminate all other places
defining underscore stuff beside in bfd. By this just one place needs
to be modified (or two pe- and pei-) and complete toolchain is
changed.
The same would be good for gcc to have an option for selecting this,
but to this I come later in mail.
> 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 :)
Agree.
> 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 :)
I thought here about the m64/m32 logic in SPEC of gcc (to be found in
mingw-w64.h and mingw32.h. Here all necessary things should be doable
AFAICS. In spec the option fleading-underscore should be probable, but
well, I have to verify it in detail. But linker-spec and the entry
point can be modified here.
> 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.
Well, for this, it would be good to have in gcc's configure a probing
rule to detect default underscoring rule. So we can do this configure
dependent to the configured binutils. This would ease configure for
user and prevent a mess of failures I can imagine here ;)
> 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...
Yeah, the underscoring needs for the collect2 tool some tweaks and
multilib version makes here most troubles. But AFAIK it should be
solvable via SPEC. For build we have to make the USER_PREFIX define
none-flag dependent and it should be the mode of the default-target.
The rest should be describable via SPEC.
Kai
--
| (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
