On Mon, Mar 22, 2010 at 3:11 PM, Kai Tietz <[email protected]> wrote:
> 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:
>
>> 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.
You actually don't even have to touch mingw32.h, only
mingw-w64.h...but i address the idea later...
>
>> 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 ;)
Agree. I don't quite know the best way to generate this detection
probe, but that's definitely the way to go...
>
>> 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.
>
Of course the following doesn't address the fact that you can't
mix-and-match the default underscoring behavior...in other words, once
you install a binutils that defaults to no underscore and a gcc that
defaults to no underscore, you cannot later install a binutils that
defaults to using the underscore without rebuilding gcc that defaults
to underscore. I don't know, would this be the right time to mention
that an abi suffix to the target type (e.g. x86_64-w64-mingw32-msabi)
or something may be appropriate here? Seems a little silly to add a
new target type just for this, but it may actually avoid some
problems.
Anyway, you could have two different mingw-w64.h files, one for
leading underscores and one for not leading underscores. The idea
would be that the gcc/configure parameter (or probe) would select the
appropriate header to generate the correct link specs. Or the same
file, but the configure machinery defines another something so that
the logic can be switched. Then, the only real changes that you would
need would be something like as follows.
(just thinking out loud here)
collect2 is pretty bad because it doesn't currently have a way of
knowing which target emulation it is using. However, you can use the
information about the link if you scan the -m <target_emul> parameter
at runtime. The COLLECT2_USER_LABEL_PREFIX stuff isn't needed unless
you are TARGET_BI_ARCH (in other words, if you don't want to deal with
multilib, you don't need the collect2 changes, since collect2 will
behave properly). Obviously this is pretty hacky but it could easily
be cleaned up...I don't really see any way of solving this otherwise,
because collect2 as far as I can tell expects that BI_ARCH compilers
always prefix the same way for both targets.
(for multilib) introduce in gcc/defaults.h, right after the default
USER_LABEL_PREFIX define this, which will default the collect2 user
label prefix to the regular user label prefix. This way you don't
need to change anything else, and collect2 behaves as it always did by
default...
#ifndef COLLECT2_USER_LABEL_PREFIX
#define COLLECT2_USER_LABEL_PREFIX USER_LABEL_PREFIX
#endif
(for multilib) Then, in collect2.c and tlink.c, use
COLLECT2_USER_LABEL_PREFIX instead of USER_LABEL_PREFIX. Then you can
define COLLECT2_USER_LABEL_PREFIX to some function that returns a
const char* that is the correct prefix based on the ABI. You also
need to have collect2 scan the command line parameters for -m
<target_emulation> so that it can set the correct abi. There's a
place in collect2 that does this for aix (i think it scans for -br64
or something), so you could do something like that for mingw64 - just
scan the parameters to collect2 for the appropriate emulation mode and
set the abi flag appropriately. There could be some logic for
detecting whether COLLECT2_USER_LABEL_PREFIX is something other than
"_" or "" so that this is the only time it is scanned (since this is
x64 mingw biarch specific)
then you can change config/i386/mingw-w64.h - you can either have two
files (this stuff split out), or you can have just the one file with a
define LEADING_UNDERSCORE_BINUTILS (set via the configuration
determining the behavior of binutils) appropriately (defined for
binutils that expects a leading underscore, undefined otherwise)...
#undef LINK_SPEC
#define LINK_SPEC SUB_LINK_SPEC " %{mwindows:--subsystem windows} \
%{mconsole:--subsystem console} \
%{shared: %{mdll: %eshared and mdll are not compatible}} \
%{shared: --shared} %{mdll:--dll} \
%{static:-Bstatic} %{!static:-Bdynamic} \
" ENTRY_LINK_SPEC " \
%(shared_libgcc_undefs)"
#if LEADING_UNDERSCORE_BINUTILS
/* Use the same entry on 32 and 64 bit. */
#define ENTRY_LINK_SPEC "%{shared|mdll: -e _dllmaincrtstar...@12
--enable-auto-image-base}"
/* No need to change USER_LABEL_PREFIX */
#else
/*
This can only be used if binutils defaults to no underscore on 64
bit minw32 side..
No BI_ARCH compiler is easy. 64bit = "", 32bit = "_"
BI_ARCH is slightly more difficult because we have to tell
collect2 that it needs to undefine the symbol and apply
fancy logic.
USER_LABEL_PREFIX originates in bsd.h
*/
#undef USER_LABEL_PREFIX
#if !TARGET_BI_ARCH
# if TARGET_64BIT_DEFAULT
# define USER_LABEL_PREFIX ""
# else
# define USER_LABEL_PREFIX "_"
# endif
#else
/* Select runtime functionality for gcc (or something similar - but
this is how WIN64 is defined) */
# define USER_LABEL_PREFIX ((TARGET_64BIT && ix86_abi == MS_ABI) ? "" : "_")
/* Select runtime functionality for collect2 */
# define COLLECT2_USER_LABEL_PREFIX
some_function_in_collect2_that_determines_prefix_based_on_abi()
#endif
/* Define the correct entry spec */
#define ENTRY_LINK_SPEC "%{shared|mdll: --enable-auto-image-base \
%{" SPEC_64 ":-e DllMainCRTStartup} \
%{" SPEC_32 ":-e _dllmaincrtstar...@12}}"
#endif /*LEADING_UNDERSCORE_DEFAULT */
------------------------------------------------------------------------------
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
