This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB 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]

RFC: merge std-operator.def and ada-operator.def?


Hello,

This is something I noticed while investigating something else: There
is no public function that prints a string image of an exp_opcode
enum. Digging deeper, I found "op_name", and eventually made it non-
static. I also found op_name_standard, but it only handled "standard"
opcodes, which, in pratice, means everything-but-Ada.

Thinking about all this, and knowing the fact that std-operator actually
also contains some language-specific operators as well (Eg Fortran's
OP_F90_RANGE), it seemed to me that this separation was causing some
unnecessary complexity in our code. The basic observation is that, to
print an opcode, you had to go through the language vector.

This patch mini-series simplifies all this.  Two steps:
  1. Merge std-operator.def and ada-operator.def into one "operator.def";
  2. Delete the "op_name" language-specific callback in struct
     struct exp_descriptor, and make some simplications that this
     change enables.

I would be tempted to add a third pass, which would rename "op_name"
into something a little more meaningful, such as "opcode_img", or
"opcode_image" or "opcode2str", so as not to confuse it with
expprint.c:op_string which does something entirely different
(ie converts BINOP_LOGICAL_OR into "||", for instance), and may
in fact return NULL even for valid opcodes.  This third step would
not be a very large patch, since the number of callers is very small.

The patch series was tested on x86_64-linux, no regression.
Thoughts?



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