https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93751
--- Comment #8 from Alexey Neyman <stilor at att dot net> --- (In reply to Eric Botcazou from comment #6) > > 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. > > Do you really need debug information for this? This is a bare-metal application that's objcopy-ed into a plain binary. So, there is no ELF symbol table available (and obviously, no libdl's interfaces either). The application also consists of several modules so the symbols in a different module are not directly accessible to this self-debugger directly (each module is linked separately with only a defined set of symbols kept visible to other modules, by running through `objcopy --keep-global-symbols). Besides, as the module in question is a minimal self-debugger, it uses the DWARF information for other purposes such as stack traces - so it is only natural to use it to locate the data structures as well. >> 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. > > People use -g1 precisely because they cannot strip all the debug > information, otherwise they would just use -g0. And they don't use -g2 > because it's bloated so we must be careful not to do the same for -g1. To > sum up, I think that we would need some figures before changing a behavior > that has been there for 25 years. What I tried to say in the previous comment was that 90% of the -g2 bloat comes not from the *external* variables (which is what we discuss here) but from the *local* variables. But I concede that it is an increase, after all, even if not a big one. Hence I think we both agree that space-conscious applications are the primary consumers of -g1. It is just that in our case, we are also faced with the extreme bloat of -g2 but we need -g1 to do what it is currently described in the manual - just the function descriptions are not sufficient for us. So I propose to introduce a new option, e.g. `-gdwarf-external-variables` that will make GCC generate the DIEs for external variables. In other words: * `-g1` will keep the current behavior * `-g1 -gdwarf-external-variables` will do what the manual currently describes, which is also what we need Would that be acceptable?
