This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
[PATCH] print better diagnostic when no CFI support
- From: Petr HluzÃn <petr dot hluzin at gmail dot com>
- To: binutils at sourceware dot org
- Date: Sun, 8 Aug 2010 21:59:36 +0200
- Subject: [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