[PATCH] naming GCC's profile data section

[Jeff Law]

On 10/24/19 11:58 AM, David Taylor wrote:
> Our application is embedded.  And in addition to cold boot (reload
> everything; start over from scratch), we support warm boot.  As part of
> supporting warm boot, read-write data that needs to be initialized, is
> initialized by code.  And we ensure at link time that the traditional
> initialized read-write data sections (.data, .ldata, .sdata) are empty.
> 
> This presents a problem when attempting to use GCC based profiling as it
> creates read-write data in the aforementioned data sections.
> 
> This patch adds a new command line option that allows you to specify the
> name of the section where GCC puts the instrumentation data.
> 
> If the new option (-fprofile-data-section) is not specified, GCC behaves
> as before.
> 
> What's missing?  Testsuite changes.  I haven't yet figured out how to do
> automated testing of this.  To test it, I built our software, several
> thousand files, and then did an 'objdump --headers', verified that
> sections .data / .ldata / .sdata were either absent of empty, and that
> the instrumentation section had the name that I specified.
> 
> We have a copyright assignment on file from before EMC was acquired by
> Dell.  Our company lawyers assure me that it survived the acquisition
> and is still valid.
> 
> I'm sending this from GNU/Linux rather than from Windows (to avoid
> having the patch mangled), so I'm not sure what the headers will show
> for my return address.  If you wish to email me, I can be reached at
> dtaylor at emc dot com or David dot Taylor at dell dot com.  Or... you
> can just send to the gcc-patches list as I'll be reading it.
> 
> Enough verbiage, here's the ChangeLog entry and the patch...
> 
> 2019-10-23  David Taylor  <dtaylor@emc.com>
> 
> 	* common.opt (fprofile-data-section): New command line switch.
> 	* coverage.c (build_var): Add support for -fprofile-data-section.
> 	(coverage_obj_finish): Ditto.
> 	* toplev.c (process_options): Issue warning if
> 	-fprofile-data-section is specified when it is not supported.
> 	* doc/invoke.texi (Option Summary): List -fprofile-data-section.
> 	(Instrumentation Options): Document -fprofile-data-section.
I don't see anything in here particularly worrisome.  WRT testing look
at gcc.dg/pr25376.c, that shows an example of how to tell dejagnu that
you require named sections for the test and how to scan the assembler.
It merely scans for the name of the section, but you can scan for just
about anything you want.

Other tests in that directory should give you a clue how to pass your
argument to the compiler.

> Index: gcc/toplev.c
> ===================================================================
> --- gcc/toplev.c	(revision 277133)
> +++ gcc/toplev.c	(working copy)
> @@ -1665,6 +1665,12 @@
>  		      "%<-fdata-sections%> not supported for this target");
>  	  flag_data_sections = 0;
>  	}
> +      if (profile_data_section_name)
> +	{
> +	  warning_at (UNKNOWN_LOCATION, 0,
> +		      "-fprofile-data-section= not supported for this target");
> +	  profile_data_section_name = NULL;
I suspect you need some markup in the warning string.  Something like
the %<-fprofile-data-section=%> just like you see for flag_data_sections
immediately above the code you're adding.

jeff