On Wed, May 7, 2014 at 10:19 AM, Herman, Andrei <andrei_her...@codesourcery.com> wrote: > Thanks for the suggestion. > The current patch includes the following text added in gcc/doc/invoke.texi: > > @item -fforce-dwarf-lexical-blocks > Produce debug information (a DW_TAG_lexical_block) for every function > body, loop body, switch body, case statement, if-then and if-else statement, > even if the body is a single statement. Likewise, a lexical block will be > emitted for the first label of a statement. This block ends at the end of the > current lexical scope, or when a break, continue, goto or return statement is > encountered at the same lexical scope level. > This option is available when using DWARF Version 4 or higher. > > I can add the suggested sentence at the beginning of the description, to save > time for users not interested in the more detailed explanation.
Also be explicit that the option only applies to C/C++ code in the documentation. Thanks, Andrew Pinski > > Regards, > Andrei Herman > Mentor Graphics Corporation > Israel branch > > >> -----Original Message----- >> From: Mike Stump [mailto:mikest...@comcast.net] >> Sent: Wednesday, May 07, 2014 7:00 PM >> To: Herman, Andrei >> Cc: gcc-patches@gcc.gnu.org; herman_and...@mentor.com >> Subject: Re: [PATCH GCC]Add 'force-dwarf-lexical-blocks' command line >> option >> >> On May 7, 2014, at 2:32 AM, Herman, Andrei >> <andrei_her...@codesourcery.com> wrote: >> > However, code coverage tools that process the DWARF debug information >> > to implement block/path coverage need more complete lexical block >> information. >> >> So, it would be nice to give a hint in the actual documentation, why a user >> might use the flag, or for a maintainer to be able to predict exactly what >> was desired in some obscure corner of dwarf semantics given the >> documentation. I think it can be as simple as "This option is useful for >> code >> coverage tools that utilize the dwarf debug information." A user, upon >> seeing that, would then ask, do I have such a tool, say no, and then know >> they don't have to contemplate the goodness of the option further. If one >> is writing a coverage tool, upon seeing the documentation, they might then >> ask themselves, how might I use that flag profitably for my users.
