Fix one .debug_macro bug and fix -g3 on non-HAVE_AS_DWARF2_DEBUG_LINE (both .debug_macro and .debug_macinfo)

Hi!

I've noticed that -g3 (both old .debug_macinfo and new .debug_macro) doesn't
work correctly when HAVE_AS_DWARF2_DEBUG_LINE isn't defined, because
the .debug_line section is emitted before .debug_mac{ro,info} and thus
if any DW_MACINFO_start_file/DW_MACRO_GNU_start_file ops need a file
that wasn't seen so far, it will reference a .debug_line filename table
entry that isn't present.
Fixed by the second and third hunk, by just emitting .debug_line after
.debug_macro/.debug_macinfo.

With that I've discovered that lookup_filename assumes that the string
it is called in is kept around, as it stores just the pointer and not a copy
of that string.  It seems all other places that call lookup_filename already
call it with somehow persistent string and before my .debug_macro patch so
did output_macinfo, because it never freed the malloced strings.
The reason I've added the freeing was that I sometimes reuse the pointers
for something else (the transparent_include group names) and valgrind etc.
would be unhappy about unreachable malloced blocks not being freed, albeit
so close to the end of the compilation.
Instead of copying the string always the following patch just copies it
if it stored that pointer (first hunk).

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2011-07-26  Jakub Jelinek  <jakub@redhat.com>

	* dwarf2out.c (output_macinfo_op): Ensure fd->filename points
	to GC allocated copy of the string.
	(dwarf2out_finish): Emit .debug_macinfo or .debug_macro sections
	before .debug_line, not after it.


	Jakub

On Tue, Jul 26, 2011 at 10:38:09PM +0200, Jakub Jelinek wrote:
> With that I've discovered that lookup_filename assumes that the string
> it is called in is kept around, as it stores just the pointer and not a copy
> of that string.  It seems all other places that call lookup_filename already
> call it with somehow persistent string and before my .debug_macro patch so
> did output_macinfo, because it never freed the malloced strings.
> The reason I've added the freeing was that I sometimes reuse the pointers
> for something else (the transparent_include group names) and valgrind etc.
> would be unhappy about unreachable malloced blocks not being freed, albeit
> so close to the end of the compilation.
> Instead of copying the string always the following patch just copies it
> if it stored that pointer (first hunk).

Forgot to add, what this newly introduced bug caused was that when using
.file/.loc directives if the same file was included more than once the
second and following copy often wouldn't share the same .file number
with the older one and thus .debug_line grew unnecessarily.  And, it could
rarely happen that it would use a wrong file name table index too, if the
freed memory contained something that would match some filename.  And of
course could crash as any reads from freed memory.

	Jakub

On 07/26/2011 01:38 PM, Jakub Jelinek wrote:
> 	* dwarf2out.c (output_macinfo_op): Ensure fd->filename points
> 	to GC allocated copy of the string.
> 	(dwarf2out_finish): Emit .debug_macinfo or .debug_macro sections
> 	before .debug_line, not after it.

Ok.


r~