Re: -fzero-initialized-in-bss again

Re: -fzero-initialized-in-bss again

[Richard Kenner]

    > What we are discussing is what object file section each variable
    > should go into.  And what I'm saying is that this shouldn't depend on
    > whether a variable was written in C or Ada: it should only be a function
    > of language-independent attributes.

    This statement really doesn't make sense to me.  It's like saying that
    what section a variable goes into should be the same between C and
    C++; if it was true, then we should be able to delete thousands of
    lines from the C++ frontend that are concerned with section and
    linkage selection.

Not really.  What I was trying to say is that the goal is to make Ada and C
as compatible as possible in terms of data layout.  One of the reasons for
this has to do with the desire to use standard tools in an embedded
environment and most of these are designed for C.  Obviously, if there's
something about a variable in C++ that can't be expressed in C, it isn't
meaningful to do the same thing as for C.  But if there *is* a simple analogy
with C, the most user-friendly thing to do is to do exactly what C would do
with that variable.

Re: -fzero-initialized-in-bss again

[Gabriel Dos Reis]

kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes:

|     > What we are discussing is what object file section each variable
|     > should go into.  And what I'm saying is that this shouldn't depend on
|     > whether a variable was written in C or Ada: it should only be a function
|     > of language-independent attributes.
| 
|     This statement really doesn't make sense to me.  It's like saying that
|     what section a variable goes into should be the same between C and
|     C++; if it was true, then we should be able to delete thousands of
|     lines from the C++ frontend that are concerned with section and
|     linkage selection.
| 
| Not really.  What I was trying to say is that the goal is to make Ada and C
| as compatible as possible in terms of data layout.

I don't dispute that.  However, there out to be a distinction between
layout and *linkage*.  The C language has a very simply-minded model
of linkage. What people have been saying is that, it is the other
front-ends' responsability to make sure that their mapping to the C
linkage model is done right.  It does not make much sense to say that
layout compatibility ought to imply linkage compatibility.  The C++
front-end, for example, tries to be as layout compatible as possible
with C where it makes sense, but it is very careful about the linkage
mapping. 

-- Gaby

Re: -fzero-initialized-in-bss again

[Geoff Keating]

kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes:

> What we are discussing is what object file section each variable
> should go into.  And what I'm saying is that this shouldn't depend on
> whether a variable was written in C or Ada: it should only be a function
> of language-independent attributes.

This statement really doesn't make sense to me.  It's like saying that
what section a variable goes into should be the same between C and
C++; if it was true, then we should be able to delete thousands of
lines from the C++ frontend that are concerned with section and
linkage selection.

It's the responsibility of the language description (that is, the
standard) to specify what behaviour is required, and then of the
language frontend to set flags like DECL_COMMON appropriately to
get that behaviour.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: -fzero-initialized-in-bss again

[Ian Lance Taylor]

kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes:

>     Let me rephrase: if the only purpose of this line is to mimic what the
>     C compiler does with common variables and the Ada compiler doesn't
>     need common variables, let's delete the line.
> 
>     So the question that would be good to answer is: does the Ada compiler
>     need common variables?
> 
> I have non clue what a "common variable" might mean.

A common variable has semantics which more or less follow the way
FORTRAN common statements are handled.  Specifically, multiple common
definitions of a variable are permitted.  There may be exactly zero or
one non-common definition of a variable.  When there are multiple
common definitions and no non-common definition, the size of the
variable is the size of the largest common definition.

Very old C compilers used these semantics for uninitialized
definitions in C.  So, for example, a program which had "char a[10];"
in one file and "char a[100];" in another file, with no initialized
"char a[NN];" anywhere, would link without error, and "a" would wind
up as a 100 byte array.

Current C compilers use these semantics only for backward
compatibility.  Standard C doesn't actually permit doing this,
although the standard describes it as a common extension.

> What we are discussing is what object file section each variable
> should go into.  And what I'm saying is that this shouldn't depend on
> whether a variable was written in C or Ada: it should only be a function
> of language-independent attributes.

"Common" is not an object file section in the usual sense.  The
"common" section is an imaginary section, along the lines of the
"undefined" section (which holds all references to otherwise undefined
symbols).  The common section has no size or address.  Putting a
symbol in the "common" section implies that the symbol should have the
semantics defined above.

If Ada does not have variables which have semantics like those
described above, then Ada should never use the common section.
Regardless of whether -fcommon was specific.  -fcommon is, in my
opinion, really a C specific option.

Ian

Re: -fzero-initialized-in-bss again

[Richard Henderson]

On Sat, May 01, 2004 at 06:17:13PM +0200, Eric Botcazou wrote:
> Weird.  I was under the impression that this would depend upon the semantics 
> of the language.

Funny, that was my reaction as well.


r~

Re: -fzero-initialized-in-bss again

[Richard Henderson]

On Sat, May 01, 2004 at 04:52:46PM +0200, Eric Botcazou wrote:
> What about Fortran?  It seems that com.c:start_decl unconditionally sets the 
> flag, much like Ada (even without testing -fcommon).

For all I know, Fortran *does* want all its variables to be common.
Wouldn't suprise me...


r~

Re: -fzero-initialized-in-bss again

[Eric Botcazou]

> I have non clue what a "common variable" might mean.

In Ada?  Then that could simply mean that Ada doesn't need them.  We could 
then put every uninitialized variable in .bss unconditionally.

> What we are discussing is what object file section each variable
> should go into.  And what I'm saying is that this shouldn't depend on
> whether a variable was written in C or Ada: it should only be a function
> of language-independent attributes.

Weird.  I was under the impression that this would depend upon the semantics 
of the language.

-- 
Eric Botcazou

Re: -fzero-initialized-in-bss again

[Richard Kenner]

    Let me rephrase: if the only purpose of this line is to mimic what the
    C compiler does with common variables and the Ada compiler doesn't
    need common variables, let's delete the line.

    So the question that would be good to answer is: does the Ada compiler
    need common variables?

I have non clue what a "common variable" might mean.

What we are discussing is what object file section each variable
should go into.  And what I'm saying is that this shouldn't depend on
whether a variable was written in C or Ada: it should only be a function
of language-independent attributes.

Re: -fzero-initialized-in-bss again

[Eric Botcazou]

> ... this is *not* the case in C or C++.
>
> The only way a variable should *ever* wind up in COMMON is if DECL_COMMON
> is set by the front end.  Otherwise it should go in .bss or .data.

What about Fortran?  It seems that com.c:start_decl unconditionally sets the 
flag, much like Ada (even without testing -fcommon).

-- 
Eric Botcazou

Re: -fzero-initialized-in-bss again

[Eric Botcazou]

> If the goal is to treat a variable the same in Ada as it would have been
> in C, then deleting that line certainly won't do that!

Let me rephrase: if the only purpose of this line is to mimic what the C 
compiler does with common variables and the Ada compiler doesn't need common 
variables, let's delete the line.

So the question that would be good to answer is: does the Ada compiler need 
common variables?

-- 
Eric Botcazou

Re: -fzero-initialized-in-bss again

[Richard Kenner]

    If that's the only intent, let's follow Geoff's suggestion and simply
    delete the line from ada/utils.c (or at least make -fno-common the
    default).  AFAIK the problem .common is aimed at solving in C doesn't
    exist in Ada.

If the goal is to treat a variable the same in Ada as it would have been in
C, then deleting that line certainly won't do that!

Re: -fzero-initialized-in-bss again

[Eric Botcazou]

> The intent is to be compatible with C and do the same thing the C front
> end would do with a decl in the same situation.  I find the the change in
> the C front end in this regard between 2.8.1 and the present confusing.

If that's the only intent, let's follow Geoff's suggestion and simply delete 
the line from ada/utils.c (or at least make -fno-common the default).  AFAIK 
the problem .common is aimed at solving in C doesn't exist in Ada.

-- 
Eric Botcazou

Re: -fzero-initialized-in-bss again

[Eric Botcazou]

> Is the problem that -fzero-initialized-in-bss is causing a zero
> initialized variable to become a common variable?

Yes, precisely.

> A BSS variable should not be a common variable.  That would be wrong.

That's what the Ada compiler does: all variables that would be put in .bss 
end up in .common if -fcommon is enabled.

I guess we have to clarify a bit the relationship between Ada and .common 
then.

-- 
Eric Botcazou

Re: -fzero-initialized-in-bss again

[Eric Botcazou]

> The problem appears to be that ada/utils.c unconditionally does this
> when building a var_decl:
>
>   DECL_COMMON   (var_decl) = !flag_no_common;
>
> Is the Ada compiler really trying to make all variables, including
> ones which are initialised, common?

It does put the flag on all variables if -fcommon is enabled.

> I don't believe this is well-supported in the backend, and I'm not even
> sure what it means.  I would suggest changing this, possibly by simply
> deleting this line, or modifying it based on Ada language semantics.

The problem is that it is unclear how Ada and -fcommon relate to each other.  
I'm under the impression that -fcommon is essentially a C thing so I think 
we could at least disable it by default for Ada.

-- 
Eric Botcazou

Re: -fzero-initialized-in-bss again

[Richard Henderson]

On Fri, Apr 30, 2004 at 04:05:42PM -0400, Ian Lance Taylor wrote:
> Can you or he express it in C terms?

I doubt it.  Because...

> Is the problem that -fzero-initialized-in-bss is causing a zero
> initialized variable to become a common variable?  A BSS variable
> should not be a common variable.  That would be wrong.

... this is *not* the case in C or C++.

The only way a variable should *ever* wind up in COMMON is if DECL_COMMON
is set by the front end.  Otherwise it should go in .bss or .data.


r~

Re: -fzero-initialized-in-bss again

[Richard Kenner]

    Is the problem that -fzero-initialized-in-bss is causing a zero
    initialized variable to become a common variable?  A BSS variable
    should not be a common variable.  That would be wrong.

That's my understanding, but I could be misunderstanding.

Re: -fzero-initialized-in-bss again

[Ian Lance Taylor]

kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes:

>     Whether something like -fzero-initialized-in-bss is correct really
>     depends on language rules.  It sounds like the Ada compiler should
>     turn it off by default.  Or else the Ada compiler should default to
>     -fno-common; that is also a language rules issue.
> 
> I think Eric was a bit misleading here.  Although the problem occured
> with an Ada program, it is not language-specific and can occur in 
> any language.

Can you or he express it in C terms?

Is the problem that -fzero-initialized-in-bss is causing a zero
initialized variable to become a common variable?  A BSS variable
should not be a common variable.  That would be wrong.

But probably I misunderstand.

Ian

Re: -fzero-initialized-in-bss again

[Richard Kenner]

    Whether something like -fzero-initialized-in-bss is correct really
    depends on language rules.  It sounds like the Ada compiler should
    turn it off by default.  Or else the Ada compiler should default to
    -fno-common; that is also a language rules issue.

I think Eric was a bit misleading here.  Although the problem occured
with an Ada program, it is not language-specific and can occur in 
any language.

Re: -fzero-initialized-in-bss again

[Ian Lance Taylor]

Eric Botcazou <ebotcazou@act-europe.fr> writes:

> We recently (after the 3.4.0 release, unfortunately) discovered that the 
> default option -fzero-initialized-in-bss has an annoying side-effect for the 
> Ada compiler: it may prevent the user from overriding an object in a library 
> (e.g. the runtime) by a local, slightly modified copy of the object.

Whether something like -fzero-initialized-in-bss is correct really
depends on language rules.  It sounds like the Ada compiler should
turn it off by default.  Or else the Ada compiler should default to
-fno-common; that is also a language rules issue.

Ian

-fzero-initialized-in-bss again

[Eric Botcazou]

Hi,

We recently (after the 3.4.0 release, unfortunately) discovered that the 
default option -fzero-initialized-in-bss has an annoying side-effect for the 
Ada compiler: it may prevent the user from overriding an object in a library 
(e.g. the runtime) by a local, slightly modified copy of the object.

Let's take an example: a user wants to modify a parameter of the runtime, by 
locally tweaking s-parame.ads like so

@@ -73,7 +73,7 @@
    --  The special value of minus one indicates that the secondary
    --  stack is to be allocated from the heap instead.

-   Sec_Stack_Ratio : constant Ratio := Dynamic;
+   Sec_Stack_Ratio : constant Ratio := 10;
    --  This constant defines the handling of the secondary stack

    Sec_Stack_Dynamic : constant Boolean := Sec_Stack_Ratio = Dynamic;


When building the executable, gnatmake will locally recompile s-parame.adb 
and try link it into the executable.  But that will fail with the error 
message:

/cardiff.a/gnatmail-5_34/build-cardiff/install/lib/gcc/i686-pc-linux-gnu/3.4.1/a
dalib/libgnat.a(s-parame.o)(.data+0x0): multiple definition of 
`system__parameters__unspecified_size'
./s-parame.o(.data+0x0): first defined here


Here's what happens: the change from 'Dynamic' to '10' for Sec_Stack_Ratio 
causes the comparison that initializes Sec_Stack_Dynamic to become false, 
hence Sec_Stack_Dynamic is effectively initialized to 0.  Given that the 
option -fzero-initialized-in-bss is enabled by default, the symbol 
system__parameters__sec_stack_dynamic is moved from .data to the 
uninitialized data section.  Now -fcommon is also on by default so the Ada 
compiler puts uninitialized symbols in the .common section.  We eventually 
end up with system__parameters__sec_stack_dynamic in the .common section.

So the local object has system__parameters__sec_stack_dynamic in .common 
while the runtime has it in .data.  Therefore the linker imports s-parame.o 
from libgnat.a, thus leading to conflicts for other symbols.


A simple solution is to turn -fzero-initialized-in-bss off by default.  This 
was discussed back in July just before the 3.3.1 release, in light of other 
problems with the FreeBSD kernel and GNU Emacs on Solaris.  We feel that 
this Ada issue adds to the pile of drawbacks with having it enabled by 
default.

Would it be feasible to do it, starting with the 3.4.1 release?

-- 
Eric Botcazou