gcc iussue or ... ?

David O'Brien obrien at freebsd.org
Sat Apr 12 18:26:47 PDT 2003

On Fri, Apr 11, 2003 at 09:41:26PM -0500, Loren James Rittle wrote:
> In article < at> you write:
> > The problem is very simple.  I mantain a unix/linux port of a UO
> > emulator which works really fine natively under FreeBSD.
> Thank you for this report.  Please consider this question: What
> versions of g++/binutils were used on the various platforms?  Please
> know this: There is a per-platform and per-binutils version influence
> on mapping of program data/BSS to ELF section.  g++ 3.3 with recent
> binutils on FreeBSD *will* allocate data as you saw on debian 3.0
> (with a compiler version you didn't report).
> Created with g++ 3.3 (prerelease) with binutils
> ; size lonewolf
>    text    data     bss     dec     hex filename
> 1792215   49768 21850592        23692575        169851f lonewolf
> ; ls -l lonewolf
> -rwxr-xr-x  1 rittle  wheel  1992568 Apr 11 20:18 lonewolf*

Hi Loren,

Are you setup to easily try this with your g++ 3.3 binary + stock system
binutils?  It looks like this is due to the fact BSD's don't define
either ASM_OUTPUT_BSS or ASM_OUTPUT_ALIGNED_BSS.  From cp/decl.c:

  #if ! defined (ASM_OUTPUT_BSS) && ! defined (ASM_OUTPUT_ALIGNED_BSS)
    /* Tell the back-end to use or not use .common as appropriate.  If we say
       -fconserve-space, we want this to save .data space, at the expense of
       wrong semantics.  If we say -fno-conserve-space, we want this to
       produce errors about redefs; to do this we force variables into the
       data segment.  */
    DECL_COMMON (tem) = flag_conserve_space || ! TREE_PUBLIC (tem);

I'm not sure we should change FreeBSD to do something that purposfully
produces wrong semantics.  From your test it sounds like either GCC 3.3
or Binutils changes things for us.  I haven't updated FreeBSD to as the changes from 2.13.2 don't really change any of the
FreeBSD architectures.  The behavior change is probably due to improved
g++ utilization of ELF features, or your FreeBSD-related bug fixes in

-- David  (obrien at FreeBSD.org)

More information about the freebsd-hackers mailing list