This fixes a bug whereby #line directives inside a macro would be ignored,

thus resulting in bad line debug information.

	PR gas/16908
	* macro.c (buffer_and_nest): Honour #line directives inside
	macros.

2 files changed, 28 insertions, 0 deletions

diff --git a/gas/ChangeLog b/gas/ChangeLog
index 34fd665..d75b57f 100644
--- a/gas/ChangeLog
+++ b/gas/ChangeLog
@@ -1,3 +1,9 @@
+2014-06-17  Chris Metcalf  <cmetcalf@tilera.com>
+
+	PR gas/16908
+	* macro.c (buffer_and_nest): Honour #line directives inside
+	macros.
+
 2014-06-17 Jiong Wang <jiong.wang@arm.com>
 
 	* config/tc-arm.c (depr_it_insns): New check for inc/dec sp.
diff --git a/gas/macro.c b/gas/macro.c
index 4589bd8..d3b4e47 100644
--- a/gas/macro.c
+++ b/gas/macro.c
@@ -211,6 +211,28 @@ buffer_and_nest (const char *from, const char *to, sb *ptr,
 		  break;
 		}
 	    }
+
+	  /* PR gas/16908
+	     Apply and discard .linefile directives that appear within
+	     the macro.  For long macros, one might want to report the
+	     line number information associated with the lines within
+	     the macro definition, but we would need more infrastructure
+	     to make that happen correctly (e.g. resetting the line
+	     number when expanding the macro), and since for short
+	     macros we clearly prefer reporting the point of expansion
+	     anyway, there's not an obviously better fix here.  */
+	  if (strncasecmp (ptr->ptr + i, "linefile", 8) == 0)
+	    {
+	      char *saved_input_line_pointer = input_line_pointer;
+	      char saved_eol_char = ptr->ptr[ptr->len];
+
+	      ptr->ptr[ptr->len] = '\0';
+	      input_line_pointer = ptr->ptr + i + 8;
+	      s_app_line (0);
+	      ptr->ptr[ptr->len] = saved_eol_char;
+	      input_line_pointer = saved_input_line_pointer;
+	      ptr->len = line_start;
+	    }
 	}
 
       /* Add the original end-of-line char to the end and keep running.  */