This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[PATCH] print better diagnostic when no CFI support


Hi

If user uses ".cfi_startproc" or other CFI directive on Atmel AVR or
other architecture lacking CFI then he gets:

rtk.SX:378: Error: unknown pseudo-op: `.cfi_startproc'

Which basically means generic "you've got it wrong, dude". You get the
same message for ".i_just_made_this_up".
It would be more helpful to say "yes, I know what you want but no, I
cannot do that because XY".

The following patch makes gas print this message instead:

rtk.SX:378: Error: CFI is not supported on architecture 'elf32-avr'

By the way: Why AVR target does not understand CFI? What needs to be
done in binutils? And in GDB?

diff --unif gas.orig/read.c gas/read.c
--- gas.orig/read.c     2009-10-09 15:12:32.000000000 +0200
+++ gas/read.c  2010-08-08 21:10:06.526638800 +0200
@@ -474,6 +474,40 @@
   return get_absolute_expr (&exp);
 }

+static void
+dot_cfi_dummy (int ignored ATTRIBUTE_UNUSED)
+{
+  as_bad (_("CFI is not supported on architecture '" TARGET_FORMAT "'"));
+  ignore_rest_of_line ();
+}
+
+const pseudo_typeS dummy_cfi_pseudo_table[] =
+{
+  { "cfi_sections", dot_cfi_dummy, 0 },
+  { "cfi_startproc", dot_cfi_dummy, 0 },
+  { "cfi_endproc", dot_cfi_dummy, 0 },
+  { "cfi_def_cfa", dot_cfi_dummy, 0 },
+  { "cfi_def_cfa_register", dot_cfi_dummy, 0 },
+  { "cfi_def_cfa_offset", dot_cfi_dummy, 0 },
+  { "cfi_adjust_cfa_offset", dot_cfi_dummy, 0 },
+  { "cfi_offset", dot_cfi_dummy, 0 },
+  { "cfi_rel_offset", dot_cfi_dummy, 0 },
+  { "cfi_register", dot_cfi_dummy, 0 },
+  { "cfi_return_column", dot_cfi_dummy, 0 },
+  { "cfi_restore", dot_cfi_dummy, 0 },
+  { "cfi_undefined", dot_cfi_dummy, 0 },
+  { "cfi_same_value", dot_cfi_dummy, 0 },
+  { "cfi_remember_state", dot_cfi_dummy, 0 },
+  { "cfi_restore_state", dot_cfi_dummy, 0 },
+  { "cfi_window_save", dot_cfi_dummy, 0 },
+  { "cfi_escape", dot_cfi_dummy, 0 },
+  { "cfi_signal_frame", dot_cfi_dummy, 0 },
+  { "cfi_personality", dot_cfi_dummy, 0 },
+  { "cfi_lsda", dot_cfi_dummy, 0 },
+  { "cfi_val_encoded_addr", dot_cfi_dummy, 0 },
+  { NULL, NULL, 0 }
+};
+
 static int pop_override_ok = 0;
 static const char *pop_table_name;

@@ -525,6 +559,11 @@
   pop_table_name = "cfi";
   pop_override_ok = 1;
   cfi_pop_insert ();
+#else
+  /* Provide better diagnostic. */
+  pop_table_name = "dummy-cfi";
+  pop_override_ok = 1;
+  pop_insert(dummy_cfi_pseudo_table);
 #endif
 }


Background story: GDB handles only well-known prologues and fails to
print a backtrace for the rest. (I want to improve that - by rewriting
prolog scanner or manually adding CFI statements to lots of code.) I
had studied all the little documentation I found to not be called lazy
to RTFM. I become filled with a dream of patching every asm project
and dispelling the myth that one cannot have a stack trace in
had-crafted assembler.
And when the the hour came the thing said "sorry, I do not know what
do you mean by .cfi_startproc". A hard way of crushing my dreams.
Thanks.

-- 
Petr Hluzin


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]