https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93751
--- Comment #5 from Alexey Neyman <stilor at att dot net> ---
Well, that's exactly how I encountered this bug. We have some built-in
introspection in our binary and we noticed that GCC generates a lot of debug
info for local variables; the difference between -g and -g1 was ~75% decrease
in the size of the debugging information.
But it turned out that we cannot go to -g1, exactly because we need the ability
to find the addresses/locations of all exported objects - both functions and
data.
First, I am not sure that fixing a manual is a good idea: that would require
removing generation of such debug info for older formats to align with current
DWARF behavior ("-g1 makes GCC generate debug info only for functions"), which
is much likelier to break existing users which depend on it.
Also I think most typical executables have fewer exported data objects than
they do have functions (note that for functions, DIEs are generated even for
static ones, so the increase in size of the debugging info should be fairly
negligible. Users concerned about even such minor increases typically strip the
debug information from the binaries altogether.
But if the size is a concern, maybe have a finer-grained knobs for enabling
debug info? E.g.
`-gpublic-functions`
`-gpublic-data`
`-gall-functions`
`-gall-data`
`-gmacros`
and have `-gX` implemented as aliases to sets of these options? `-g1` would be
then translated to `-gall-functions -gpublic-data` (if implemented per manual)
or just `-gall-functions` (if current behavior is kept).
