This is the mail archive of the gdb-patches@sources.redhat.com 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]

Re: AM33/2.0 support for mn10300-elf


Sigh, separate SIM and GDB patches might have been easier.

For the simulator, two refinements:

+void fpu_disabled_exception PARAMS ((SIM_DESC, sim_cpu *, address_word));
The code needs to use strict ISO C. It might be easier to just convert everything.


+  store_word (addr + 4, data.high);
+}
 #endif  /* not WITH_COMMON */

The MN10300 switched to sim/common long ago, the #if !WITH_COMMON code should be deleted.

they can both be considered pretty "obvious".

Other than that, its approved.

--

+/* Fetch, and possibly build, an appropriate link_map_offsets structure
+   for mn10300 linux targets using the struct offsets defined in <link.h>.
+   Note, however, that link.h is not actually referred to in this file.
+   Instead, the relevant structs offsets were obtained from examining
+   link.h.  (We can't refer to link.h from this file because the host
+   system won't necessarily have it, or if it does, the structs which
+   it defines will refer to the host system, not the target.)  */
+
+struct link_map_offsets *
+mn10300_linux_svr4_fetch_link_map_offsets (void)
+{

This really belongs in mn10300-linux-tdep.c. I also suspect that stuff is also missing from the patch (tm-mn10300.h?), as the function doesn't appear to be called? Does this need an ABI sniffer (see osabi.[sh])?


+ if (AM33_MODE == 2)

I'm guessing this is a macro that relies on global state. New code instead accesses everything via parameters. Here, something like:


fi->arch->tdep->am33_mode

which, in GDB, is written as:

gdbarch_tdep (get_frame_arch (fi))->am33_mode.

+ get_frame_saved_regs (fi)[LAR_REGNUM] = get_frame_base (fi) + offset + 4;

See: http://sources.redhat.com/gdb/current/ari/
The method get_frame_saved_regs() is obsolete. Changes should be decreasing, not increasing that function's usage count :-/ The new code will need to be written in a way that avoids this method. The best way of doing this is to convert it to convert that section of the code to the new unwind mechanism.


     15, 16, 17, 18, 19, 20, 21, 22
+    , 32, 33, 34, 35, 36, 37, 38, 39
+    , 40, 41, 42, 43, 44, 45, 46, 47

GNU coding style?



+ set_gdbarch_fp0_regnum (gdbarch, 32);


Is this needed? Adding a field to the am33's tdep struct would be better. FP0_REGNUM is almost, but not quite deprecated.

sorry,
Andrew


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