This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: Large data sections support
- From: Jan Hubicka <jh at suse dot cz>
- To: Jan Beulich <JBeulich at novell dot com>
- Cc: jh at suse dot cz, hjl at lucon dot org, rth at redhat dot com,binutils at sources dot redhat dot com, hubicka at ucw dot cz
- Date: Mon, 13 Jun 2005 09:56:29 +0200
- Subject: Re: Large data sections support
- References: <s2ace2bb.044@lyle.provo.novell.com>
> >>>> Jan Hubicka <jh@suse.cz> 13.06.05 09:29:09 >>>
> >> On Mon, Jun 13, 2005 at 01:22:00AM +0200, Jan Hubicka wrote:
> >> > Yeah :( If lcomm/large_comm really looks superrior I can try work on
> >> > this but I would preffer the easier route here...
> >>
> >> I think we do need something to mark these symbols specially.
> >> Something pretty much exactly like SHN_PARISC_HUGE_COMMON sounds
> >> like it means.
> >
> >I might propose the ABI change here, but will this work when we mix
> >small and medium model units where symbols will get conflicting flags?
> >(ie we want library compiled for medium model to link with small model
> >program as long as overall the binary is small enought to fit small
> >model limitations).
>
> As always, you'd have to enforce the more restrictive storage (that is, the object would have to go into .bss rather than .lbss if at least one declaration uses SHN_COMMON).
I was sort of wondering what kind of advantage it would buy us avoiding
linker to decide it for us when the meaning of flag is not definite, but
I guess it would avoid us for requiring to tell linker whether we are
building small or medium model binary. So I guess I will just follow
PARISC implementation and propose the ABI change here...
Honza
>
> Jan
>