Re: allow preferring linking against dynamic libgcc over static one

Re: allow preferring linking against dynamic libgcc over static one

[Jan Beulich]

This sounds rather good. When I first wrote the change,
DRIVER_SELF_SPECS didn't exist yet. After that I just continued bringing
it forward since I didn't notice the enhancement. Thanks for pointing
this out. Jan

>>> Alexandre Oliva <aoliva@redhat.com> 07.07.04 20:50:09 >>>
On Jul  7, 2004, "Jan Beulich" <JBeulich@novell.com> wrote:

> 2004-07-07 Jan Beulich <jbeulich@novell.com>

> 	* gcc.c (init_gcc_specs): Conditionalize upon
> PREFER_SHARED_LIBGCC.

Instead of introducing this new macro, how about just doing it with a
machine/os-specific:

#define DRIVER_SELF_SPECS "%{!static-libgcc:-shared-libgcc}"

?

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/ 
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}

Re: allow preferring linking against dynamic libgcc over static one

[Alexandre Oliva]

On Jul  7, 2004, "Jan Beulich" <JBeulich@novell.com> wrote:

> 2004-07-07 Jan Beulich <jbeulich@novell.com>

> 	* gcc.c (init_gcc_specs): Conditionalize upon
> PREFER_SHARED_LIBGCC.

Instead of introducing this new macro, how about just doing it with a
machine/os-specific:

#define DRIVER_SELF_SPECS "%{!static-libgcc:-shared-libgcc}"

?

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}

Re: allow preferring linking against dynamic libgcc over static one

[Joseph S. Myers]

On Wed, 7 Jul 2004, Paolo Bonzini wrote:

> I think you should go ahead with target macros, since having a hook 
> seems overkill when the target macro is actually going to return a 
> constant everywhere.

In the case of PREFER_SHARED_LIBGCC that probably makes sense.  For
MERGE_SECTION_SEPARATOR, targetm.asm_out is fairly well developed (though
not complete), and includes both constant strings as well as functions, so
I think anything new about how assembler is output should go in there.  
(Also, if having anything about how assembler is output as a hook rather
than a macro makes a measurable performance difference, either something
is very wrong about how we output assembler, or we've made extraordinary
order-of-magnitude improvements to the speed of the rest of the compiler.)

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
    jsm@polyomino.org.uk (personal mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)

Re: allow preferring linking against dynamic libgcc over static one

[Joseph S. Myers]

On Wed, 7 Jul 2004, Jan Beulich wrote:

> This is puzzling. In the very same place there is use of
> USE_LD_AS_NEEDED, introduced in April. Why would the rules you try to
> enforce here not hold for that one (it's neither documented nor being
> checked for at runtime)? Jan

Thank you for pointing out this regression in documentedness.  I have
filed bug 16406 accordingly for the undocumentedness of this macro.  The
requirements apply to everyone, but not every patch necessarily gets
adequately checked.  In that case, runtime checking is more difficult as
the conditional controls a sequence of arguments to a function call rather
than whole statements.  The principle of runtime checkability is mentioned
in projects/beginner.html and is one that still applies where possible.

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
    jsm@polyomino.org.uk (personal mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)

Re: allow preferring linking against dynamic libgcc over static one

[Paolo Bonzini]

> This is puzzling. In the very same place there is use of
> USE_LD_AS_NEEDED, introduced in April. Why would the rules you try to
> enforce here not hold for that one (it's neither documented nor being
> checked for at runtime)? Jan

Probably because this slipped through.  Joseph is probably one of the 
most thorough people in the GCC developer community, but he cannot be 
always there reminding people to update the docs.

I think you should go ahead with target macros, since having a hook 
seems overkill when the target macro is actually going to return a 
constant everywhere.

Also, though you're indeed breaking up the patch which makes it much 
easier to review, it will probably be easier for you as well if you 
submit only 2 or 3 of them at a single time.

Keep ten CVS checkouts, each with a single patch (apart from maybe the 
final NetWare target tree, which will be "your" local tree), and submit 
two cvs diff's at a time. When they are okayed and committed (you don't 
have CVS write access yet, have you?), update all the trees.  It is much 
easier to track what has been reviewed and what not, both for you and 
for the GCC maintainers.

Good luck,

Paolo

Re: allow preferring linking against dynamic libgcc over static one

[Paolo Bonzini]

> This is puzzling. In the very same place there is use of
> USE_LD_AS_NEEDED, introduced in April. Why would the rules you try to
> enforce here not hold for that one (it's neither documented nor being
> checked for at runtime)? Jan

Probably because this slipped through.  Joseph is probably one of the 
most thorough people in the GCC developer community, but he cannot be 
always there reminding people to update the docs.

I think you should go ahead with target macros, since having a hook 
seems overkill when the target macro is actually going to return a 
constant everywhere.

Also, though you're indeed breaking up the patch which makes it much 
easier to review, it will probably be easier for you as well if you 
submit only 2 or 3 of them at a single time.

Keep ten CVS checkouts, each with a single patch (apart from maybe the 
final NetWare target tree, which will be "your" local tree), and submit 
two cvs diff's at a time. When they are okayed and committed (you don't 
have CVS write access yet, have you?), update all the trees.  It is much 
easier to track what has been reviewed and what not, both for you and 
for the GCC maintainers.

Good luck,

Paolo

Re: allow preferring linking against dynamic libgcc over static one

[Jan Beulich]

This is puzzling. In the very same place there is use of
USE_LD_AS_NEEDED, introduced in April. Why would the rules you try to
enforce here not hold for that one (it's neither documented nor being
checked for at runtime)? Jan

>>> "Joseph S. Myers" <jsm@polyomino.org.uk> 07.07.04 13:57:30 >>>
On Wed, 7 Jul 2004, Jan Beulich wrote:

> 2004-07-07 Jan Beulich <jbeulich@novell.com>
> 
> 	* gcc.c (init_gcc_specs): Conditionalize upon
> PREFER_SHARED_LIBGCC.

Apart from needing documentation for any new target macros and hooks,
it's
better to check such macros - if you use a macro rather than a hook -
with
if (PREFER_SHARED_LIBGCC) (and to have a default definition in
defaults.h)
rather than #ifdef/#ifndef (if the macro is constant, the other side
will
get optimized out, but will still get checked for syntax so be a bit
less
likely to bitrot).

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/ 
    jsm@polyomino.org.uk (personal mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)

Re: allow preferring linking against dynamic libgcc over static one

[Joseph S. Myers]

On Wed, 7 Jul 2004, Jan Beulich wrote:

> 2004-07-07 Jan Beulich <jbeulich@novell.com>
> 
> 	* gcc.c (init_gcc_specs): Conditionalize upon
> PREFER_SHARED_LIBGCC.

Apart from needing documentation for any new target macros and hooks, it's
better to check such macros - if you use a macro rather than a hook - with
if (PREFER_SHARED_LIBGCC) (and to have a default definition in defaults.h)
rather than #ifdef/#ifndef (if the macro is constant, the other side will
get optimized out, but will still get checked for syntax so be a bit less
likely to bitrot).

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
    jsm@polyomino.org.uk (personal mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)

allow preferring linking against dynamic libgcc over static one

[Jan Beulich]

[-- Attachment #1: Type: text/plain, Size: 1051 bytes --]

For targets that prefer linking against a dynamic libgcc over a static
one,
add respective support. The soon to be submitted NetWare target patch
will
make use of this.

2004-07-07 Jan Beulich <jbeulich@novell.com>

	* gcc.c (init_gcc_specs): Conditionalize upon
PREFER_SHARED_LIBGCC.

---
/home/jbeulich/src/gcc/mainline/2004-07-05.10.09/gcc/gcc.c	2004-07-02
15:13:35.000000000 +0200
+++ 2004-07-05.10.09/gcc/gcc.c	2004-07-06 08:57:15.533494752 +0200
@@ -1591,6 +1591,7 @@
 {
   char *buf;
 
+#ifndef PREFER_SHARED_LIBGCC
   buf = concat ("%{static|static-libgcc:", static_name, " ", eh_name,
 		"}%{!static:%{!static-libgcc:",
 #if USE_LD_AS_NEEDED
@@ -1610,6 +1611,13 @@
 #endif
 #endif
 		"}}}", NULL);
+#else
+  buf = concat ("%{shared-libgcc:", shared_name,
+		"}%{!shared-libgcc:%{static-libgcc:",
+		static_name, " ", eh_name,
"}%{!static-libgcc:%{shared:",
+		shared_name, "}%{!shared:%{static:", static_name, " ",
eh_name,
+		"}%{!static:", shared_name, "}}}}", NULL);
+#endif
 
   obstack_grow (obstack, buf, strlen (buf));
   free (buf);


[-- Attachment #2: gcc-mainline-prefer-shared-libgcc.patch --]
[-- Type: application/octet-stream, Size: 1049 bytes --]

For targets that prefer linking against a dynamic libgcc over a staic one, add
repsective support. The soon to be submitted NetWare target patch will make
use of this.

2004-07-07 Jan Beulich <jbeulich@novell.com>

	* gcc.c (init_gcc_specs): Conditionalize upon PREFER_SHARED_LIBGCC.

--- /home/jbeulich/src/gcc/mainline/2004-07-05.10.09/gcc/gcc.c	2004-07-02 15:13:35.000000000 +0200
+++ 2004-07-05.10.09/gcc/gcc.c	2004-07-06 08:57:15.533494752 +0200
@@ -1591,6 +1591,7 @@
 {
   char *buf;
 
+#ifndef PREFER_SHARED_LIBGCC
   buf = concat ("%{static|static-libgcc:", static_name, " ", eh_name,
 		"}%{!static:%{!static-libgcc:",
 #if USE_LD_AS_NEEDED
@@ -1610,6 +1611,13 @@
 #endif
 #endif
 		"}}}", NULL);
+#else
+  buf = concat ("%{shared-libgcc:", shared_name,
+		"}%{!shared-libgcc:%{static-libgcc:",
+		static_name, " ", eh_name, "}%{!static-libgcc:%{shared:",
+		shared_name, "}%{!shared:%{static:", static_name, " ", eh_name,
+		"}%{!static:", shared_name, "}}}}", NULL);
+#endif
 
   obstack_grow (obstack, buf, strlen (buf));
   free (buf);