On 11/30/20 1:29 PM, Jeff Law wrote:
On 11/17/20 7:09 PM, Martin Sebor wrote:
On 11/16/20 4:54 PM, Jeff Law wrote:
On 11/16/20 2:04 AM, Richard Biener via Gcc-patches wrote:
On Sun, Nov 15, 2020 at 1:46 AM Martin Sebor via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:
GCC considers PTRDIFF_MAX - 1 to be the size of the largest object
so that the difference between a pointer to the byte just past its
end and the first one is no more than PTRDIFF_MAX. This is too
liberal in LP64 on most systems because the size of the address
space is constrained to much less than that, both by the width
of the address bus for physical memory and by the practical
limitations of disk sizes for swap files.
Shouldn't this be a target hook like MAX_OFILE_ALIGNMENT then?
I think one could argue either way. Yes, the absolutes are a function
of the underlying hardware and it can change over the lifetime of a
processor family which likey differs from MAX_OFILE_ALIGNMENT.
A PARAM gives the developer a way to specify the limit which is more
flexible.
What I'm not really not sure of is whether is really matters in practice
for end users.
I'd like to do two things with this change: 1) make it easier
(and encourage users) to detect as early as possible more bugs
due to excessive sizes in various function calls (malloc, memcpy,
etc.), and 2) verify that GCC code uses the limit consistently
and correctly.
I envision the first would appeal to security-minded distros
and other organizations that use GCC as their system compiler.
For those, a target hook would be more convenient than a --param.
But I also expect individual projects wanting to impose stricter
limits than distros select. For those, a --param is the only
choice (aside from individual -Wlarger-than- options(*)).
With this in mind, I think providing both a target hook and
a --param has the best chance of achieving these goals.
The attached patch does that.
Martin
[*] To enforce more realistic object size limits than PTRDIFF_MAX,
GCC users today have to set no fewer than five (or six if we count
-Wstack-usage) options: -Walloca-larger-than,
-Walloc-size-larger-than, -Wframe-larger-than, -Wlarger-than, and
-Wvla-larger-than. The limits are all independent of one another.
I expect providing a single configurable baseline value for all
these options to use and refine to be helpful to these users.
gcc-max-objsize.diff
The more I think about this, the more I think it's not really useful in
practice.
I don't see distros using this flag as there's likely no good values a
distro could use that would likely catch bogus code without needlessly
flagging valid code.
Red Hat documents 128TB of maximum x86_64 per-process virtual address
space:
https://access.redhat.com/articles/rhel-limits
My understanding is that no x86_64 implementation exists that supports
objects larger than 2^48 bytes. AFAIK, other 64-bit architectures and
operating system have similar limits. The Red Hat page mentions limits
for all our supported architectures.
I don't see individual projects using this code either -- for the most
part I would not expect a project developer to be able to accurately
predict the maximum size of allocations they potentially perform and
then bake that into their build system. There are exceptions (kernel &
embedded systems come immediately to mind).
They can refer to documentation like the RHEL link above to figure
that out. But even with 64-bit addresses, the size of the virtual
address space is limited by the amount of physical memory and
the size of the swap file (limited by the size of the disk), and
for practical purposes, by the transfer rate of the disk. So with
some math, those who care about these things can easily come up
with a more realistic limit for their application than PTRDIFF_MAX.
And finally, I'm really not a fan of --params for end-user needs. Those
feel much more like options that we as GCC developers use to help
ourselves rather than something we encourage others to use.
I don't insist on it to be a parameter. Whatever other knob will
work as well. I just thought this is what parameters were for(*).
Will you approve the patch with the parameter changed to an option?
Say -fmax-object-size, or would I be wasting my time?
Martin
[*] Options intended for GCC developers are documented in section
named GCC Developer Options. --params are documented in section
named Options That Control Optimization. If --params are mainly
meant for GCC developers then they're in the wrong section.
