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. -- 宋方睿