On Fri, May 26, 2023 at 12:11 AM Jan Beulich <jbeul...@suse.com> wrote:
>
> On 25.05.2023 18:11, Fangrui Song wrote:
> > On 2023-05-25, Jan Beulich wrote:
> >> On 25.05.2023 17:16, Fangrui Song wrote:
> >>> --- a/gcc/doc/invoke.texi
> >>> +++ b/gcc/doc/invoke.texi
> >>> @@ -32942,9 +32942,10 @@ the cache line size. @samp{compat} is the
> >>> default.
> >>>
> >>> @opindex mlarge-data-threshold
> >>> @item -mlarge-data-threshold=@var{threshold}
> >>> -When @option{-mcmodel=medium} is specified, data objects larger than
> >>> -@var{threshold} are placed in the large data section. This value must
> >>> be the
> >>> -same across all objects linked into the binary, and defaults to 65535.
> >>> +When @option{-mcmodel=medium} or @option{-mcmodel=large} is specified,
> >>> data
> >>> +objects larger than @var{threshold} are placed in large data sections.
> >>> This
> >>> +value must be the same across all objects linked into the binary, and
> >>> defaults
> >>> +to 65535.
> >>
> >> Where's the "must be the same" requirement coming from?
> >
> > It's an existing requirement. I think it may be related to discouraging
> > different COMDAT sections names due to different -mlarge-data-threshold=.
> > I don't think it makes sense but did not feel strongly dropping it.
> >
> > Happy to drop the requirement if I revise this patch.
>
> I understand that this isn't something you introduce, but it still stuck
> me as odd. Therefore I thought I'd suggest to take the opportunity to at
> least soften the language, unless of course there's a real reason behind
> it.
Dropping "This value must be the same across all objects linked into
the binary" looks good to me.
> >> As to the default - to remain compatible with earlier versions, shouldn't
> >> large model code default to "infinity"?
> >>
> >> Jan
> >
> > I have thought about this compatibility need and feel that it is very
> > unlikly to be needed. GNU ld has supported large data sections since
> > 2005
> > (https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=3b22753a67cf616514de804ef6d5ed5e90a7d883).
> > Users' programs with the internal linker scripts will still be working
> > and -fdata-sections sections will be combined.
>
> Well, the concern clearly is about custom scripts. Imo ...
>
> > First, -mcmodel=large use cases are rare enough. Rare perhaps
> > -mcmodel=largel was considered theoretic excercise in
> > trying to reach feature completion
> > (https://groups.google.com/g/x86-64-abi/c/jnQdJeabxiU/m/NNuA0P7pAQAJ),
> > without this patch -mcmodel=large object files don't interract well with
> > existing -mcmodel=small object files.
>
> ... the more exotic a project, the more likely it is that they're using
> custom scripts.
>
> > Moreover, if a user expects a specific section prefix with
> > -mcmodel=large, that's a brittle assumption. I think it's fair to say
> > that the fault is on the user side and GCC doesn't need to work around
> > their issues.
>
> I guess I don't really see what you base this on. Without any special
> options, expecting data to end up in .data/.bss/.rodata (and variants
> thereof) looks like quite reasonable an assumption to me.
>
> Jan
Making -mlarge-data-threshold= default value for
-mcmodel={medium,large} seems quite odd to me.
The default value is 65536, which is larger than most data objects
that we may encounter in practice.
I want to investigate how often users use -mcmodel=large but it is
quite difficult. Many are for AIX and/or powerpc.
I have tried to be considerate but I am not sure we have users in the
intersection of the three sets: -mcmodel=large, data objects larger
than 65536, using linker script in a way that orphan sections .ldata
will cause trouble.
--
宋方睿
