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]

Re: [patch] add target Score to GDB


qinwei@sunnorth.com.cn writes:
> If we won't open simulator source, can we put simulator libs(11 libs) and 
> simstub.c in the dir 'gdb-6.5/sim/score'?
> If we can, i will send you these libs. 
> Otherwise, i post the patch in the following just containing 'score' gdb 
> but without simulator.

The GDB source tree cannot contain non-Free software.  We give our
users all the rights to modify and redistribute the software that we
have, on the condition that they do the same for others; that's the
founding principle of Project GNU.  Including non-free libraries with
GDB would not follow that principle.

We encourage you to free your simulator; if that's not possible, then
we'll need to leave the simulator out.

> I diff gdb-6.5 gdb-6.5-score in the top-level and the result is the 
> following. 
> Thanks for checking my patch and i hope to hear your advice on 
> score-tdep.c.

You need to run 'diff -ruN', so it shows the contents of newly added
files.  I'll look at the score-tdep.[ch] files from your post
yesterday.

It looks as if the ROUND_UP macro is not used.

In score_analyze_pdr_section, you probably want to use the following
functions declared in objfiles.h, instead of the
deprecated_obj_private pointer:

  /* Keep a registry of per-objfile data-pointers required by other GDB
     modules.  */

  extern const struct objfile_data *register_objfile_data (void);
  extern void clear_objfile_data (struct objfile *objfile);
  extern void set_objfile_data (struct objfile *objfile,
                                const struct objfile_data *data, void *value);
  extern void *objfile_data (struct objfile *objfile,
                             const struct objfile_data *data);

I see that you don't use any other deprecated features, which is good.

Do you need to define the read_pc and write_pc functions?  If you
leave them out, regcache.c's read_pc_pid and write_pc_pid should fall
back to default functions which will do the ptid-swapping for you,
making score_read_unsigned_register_pid, score_read_pc, and
score_write_pc unnecessary

Does the S+core architecture allow you to mix 32-bit and 16-bit
instructions?  If so, could score_breakpoint_from_pc be simplified to
always return a 16-bit breakpoint?  This would mean that a breakpoint
inserted at a 32-bit instruction would produce two bytes of garbage
after the breakpoint, but that's normal; on the i386, GDB uses a
one-byte breakpoint instruction regardless of the length of the
instruction it's set at.

Does score_integer_to_address do exactly the same thing that GCC does
when the user casts an integer to an address?  If they don't, then the
user could become quite confused when GDB and GCC evaluate their
expressions differently.

Future revisions of GCC change the sorts of prologues GDB will
encounter.  If you find yourself investing more time than you expected
on score_analyze_prologue, consider using the framework in
prologue-value.h, documented there.


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