This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: section() handling changed (or a bug was introduced)?
On Wed, Oct 20, 2004 at 11:45:12AM +0200, Mariusz Mazur wrote:
> On ?roda 20 pa?dziernik 2004 00:24, Daniel Jacobowitz wrote:
> > > [builder2@storm builder2]$ cat test.s
> > > .file "test.c"
> > > .globl __sparc32_atomic_locks
> > > .section .bss,"awG",@nobits,.__sparc32_atomic_locks,comdat
> > > .align 32
> > > .type __sparc32_atomic_locks, @object
> > > .size __sparc32_atomic_locks, 64
> > > __sparc32_atomic_locks:
> > > .zero 64
> > > .section .note.GNU-stack,"",@progbits
> > > .ident "GCC: (GNU) 3.4.3 20041008 (prerelease) (PLD Linux)"
> > >
> > >
> > > Obviously the second example is broken. Is this some kind of changed
> > > syntax (haven't found anything about it with google) or just a plain bug?
> >
> > Two things:
> > - While changing a user-specified section name is a little dubious,
> > i.e. probably no one thought about it, the second sample looks right to
> > me. It crashes binutils 2.15 but is accepted by binutils HEAD. Ew.
>
> The second example causes creation of 'global' objects in symbols table in
> object files (.bss[.__sparc32_atomic_locks]) which in turn means that these
> global objects conflict when linking. And it's obvious that they shouldn't
> (and glibc depends on the fact, that those object remain local).
It's not a global/local question; but it wants there to be only one
copy. Then your linker doesn't really support comdat; if it did, they
would not conflict.
--
Daniel Jacobowitz