This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Things in specs vs. things explicit in the generated source [was Re: [PATCH] Pass -mtune and -march options to assembler.]


Mark Mitchell wrote:

> I agree with you that people *should* assemble .s files with "gcc".
> But, in practice, many of them assemble them with "as" -- just as many
> people link with "ld".  (We still install these tools in $bindir, not in
> $libexecdir, which is what we should do if we really don't want people
> using them...)  In any case, relying on specs is error-prone; it's
> subject to users failing to pass the right flags, invoking the wrong
> tool, and on changes to specs processing over time.  In contrast,
> putting the information in the assembly file accurately conveys the
> user's intent when performing the initial compilation.

  So, what does everyone think of putting something like this in a spec:

+/* To implement C++ function replacement we always wrap the cxx
+   malloc-like operators.  See N2800 #17.6.4.6 [replacement.functions] */
+#define CXX_WRAP_SPEC "\
+  --wrap _Znwj \
+  --wrap _Znaj \
+  --wrap _ZdlPv \
+  --wrap _ZdaPv \
+  --wrap _ZnwjRKSt9nothrow_t \
+  --wrap _ZnajRKSt9nothrow_t \
+  --wrap _ZdlPvRKSt9nothrow_t \
+  --wrap _ZdaPvRKSt9nothrow_t "

... and relying on it being applied consistently for strict C++ conformance?

  (Background: I'm trying to make libstdc++ work as a DLL on windows; windows
DLLs differ from ELF .SOs as they must be fully-resolved at link time; this
means that e.g. calls to operator new from within libstdc++ itself have to be
resolved when the DLL is compiled, and won't subsequently take note if there's
a replacement definition available when an application gets finally linked.
So, making all C++ libs link against wrappers that can be redirected at
runtime according to the replacement functions available in the exe seems like
the way to go, but is this the way to do it?)

    cheers,
      DaveK


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]