[patch] add target Score to GDB

[patch] add target Score to GDB

[bjgnu]

[-- Attachment #1: Type: text/plain, Size: 2494 bytes --]

Hello Maintainers,

I'v ported GDB-6.5.90 to Score target and SunNorth has assigned the forms 
to the FSF.
The following is a patch adding Score target to GDB and i hope i could be 
the Score maintainer.
I'v posted the patch to gdb@sourceware.org on 2006.12.4, but get no reply, 
maybe it's a wrong place. 
Could anyone help me checking my patch? I really appreciate your help. 
I've checkout the current-cvs and all testpatterns run pass in DejaGNU.
Some FAILs are target dependent. I've checked these FAILs and they are not 
gdb bug. 
I hope Score target can be added to GDB-6.6 if possible.

1, Modify gdb-6.5/gdb/configure.tgt:
diff -pu -r gdb-6.5/gdb/configure.tgt gdb-6.5-score/gdb/configure.tgt
--- gdb-6.5/gdb/configure.tgt   2006-11-22 17:31:03.000000000 +0800
+++ gdb-6.5-score/gdb/configure.tgt 2006-11-22 17:48:36.000000000 +0800
@@ -21,6 +21,7 @@ m68*)         gdb_target_cpu=m68k ;;
 m88*)          gdb_target_cpu=m88k ;;
 mips*)         gdb_target_cpu=mips ;;
 powerpc*)      gdb_target_cpu=powerpc ;;
+score*)            gdb_target_cpu=score ;;
 sparc*)            gdb_target_cpu=sparc ;;
 thumb*)            gdb_target_cpu=arm ;;
 s390*)         gdb_target_cpu=s390 ;;
@@ -174,6 +175,7 @@ rs6000-*-lynxos*)   gdb_target=rs6000lynx 
 rs6000-*-aix4*)        gdb_target=aix4 ;;
 rs6000-*-*)        gdb_target=rs6000 ;;
 
+score-*-*)         gdb_target=embed ;;
 s390*-*-*)     gdb_target=s390
            build_gdbserver=yes
            ;;

2, Modify gdb-6.5/sim/configure:
diff -pu -r gdb-6.5/sim/configure gdb-6.5-score/sim/configure
--- gdb-6.5/sim/configure   2006-11-22 17:31:05.000000000 +0800
+++ gdb-6.5-score/sim/configure 2006-11-22 17:48:36.000000000 +0800
@@ -284,6 +284,7 @@ ac_subdirs_all="$ac_subdirs_all m68hc11"
 ac_subdirs_all="$ac_subdirs_all mcore"
 ac_subdirs_all="$ac_subdirs_all mips"
 ac_subdirs_all="$ac_subdirs_all mn10300"
+ac_subdirs_all="$ac_subdirs_all score"
 ac_subdirs_all="$ac_subdirs_all sh64"
 ac_subdirs_all="$ac_subdirs_all sh"
 ac_subdirs_all="$ac_subdirs_all erc32"
@@ -3510,6 +3511,14 @@ subdirs="$subdirs mn10300"
       common=yes
       igen=yes
       ;;
+       score*-*-*)
+
+
+subdirs="$subdirs score"
+
+      testsuite=yes
+      common=yes
+      ;;
        sh64-*-*)

3, Add the following directories and files:
1) gdb-6.5/gdb/config/score;
2) gdb-6.5/gdb/score-tdep.c;
3) gdb-6.5/gdb/score-tdep.h;
4) gdb-6.5/sim/score;


Best regards,
Qinwei
Mail  qinwei@sunnorth.com.cn
Phone +86-010-62981668-2708
Fax   +86-010-62985972





[-- Attachment #2: Score_GDB_patch.tar.gz --]
[-- Type: application/octet-stream, Size: 47374 bytes --]

Re: [patch] add target Score to GDB

[Jim Blandy]

bjgnu@sunnorth.com.cn writes:
> I'v ported GDB-6.5.90 to Score target and SunNorth has assigned the forms 
> to the FSF.
> The following is a patch adding Score target to GDB and i hope i could be 
> the Score maintainer.
> I'v posted the patch to gdb@sourceware.org on 2006.12.4, but get no reply, 
> maybe it's a wrong place. 
> Could anyone help me checking my patch? I really appreciate your help. 
> I've checkout the current-cvs and all testpatterns run pass in DejaGNU.
> Some FAILs are target dependent. I've checked these FAILs and they are not 
> gdb bug. 
> I hope Score target can be added to GDB-6.6 if possible.

Hi, Qinwei.  gdb-patches is the right mailing list for this.  However,
it may take us a while to review patches; there aren't very many
reviewers.  If you don't get a response within a week, then please
post a 'ping' patch.

Your work is more likely to be reviewed if you post it as a multi-file
patch which can be applied by running 'patch -p0 < foo.patch' in the
top-level source directory.  Unified diffs (diff -u) seem to be the
preferred format.

Your embed.mt file says:

    OOLIB_PATH=../../sim_lib/oolib_install
    TDEPFILES= score-tdep.o 
    SIM_OBS= remote-sim.o
    TM_CLIBS = -L $(OOLIB_PATH)/lib -lsc_gdb -lsc_tools -lsc_sim -lsc_ice -lprobe -lscore -lsocshell -lsoc -lpackages -lstdc++ -lSDL -lSDL_image
    SIM= ../sim/score/libsim.a 

It looks to me as if this means that the 'score' target depends on a
simulator located outside the GDB tree.  Is this simulator Free
software?  Please make sure your GDB satisfies the license conditions
explained in the COPYING file.  If you can release the simulator as
Free software as well, that would be best.  Otherwise, you may be able
to satisfy the license simply by building GDB without the simulator.

It seems the simulator in your post is just a stub.  We would rather
not have stub code in GDB.

I don't see a patch to 'sim/configure.in' in your post.
'sim/configure' is generated automatically from configure.in using
autoconf.  Patches should generally not include changes to generated
files, like 'configure', because they can be large.

I have some comments on score-tdep.c, but let's get the above issues
sorted out first.

Finally, I don't know how Joel Brobecker, our release manager, feels
about including new ports this late in the process.  On the one hand,
if the port is self-contained, it is unlikely to break other code.  On
the other hand, we have already produced our first release candidate.
I'll leave the decision to him.

Thanks for posting this port!

Re: Re: [patch] add target Score to GDB

[qinwei]

[-- Attachment #1: Type: text/plain, Size: 4327 bytes --]

Jim Blandy <jimb@codesourcery.com> 写于 2006-12-06 04:00:46:

> 
> bjgnu@sunnorth.com.cn writes:
> > I'v ported GDB-6.5.90 to Score target and SunNorth has assigned the 
forms 
> > to the FSF.
> > The following is a patch adding Score target to GDB and i hope i could 
be 
> > the Score maintainer.
> > I'v posted the patch to gdb@sourceware.org on 2006.12.4, but get no 
reply, 
> > maybe it's a wrong place. 
> > Could anyone help me checking my patch? I really appreciate your help. 

> > I've checkout the current-cvs and all testpatterns run pass in 
DejaGNU.
> > Some FAILs are target dependent. I've checked these FAILs and they are 
not 
> > gdb bug. 
> > I hope Score target can be added to GDB-6.6 if possible.
> 
> Hi, Qinwei.  gdb-patches is the right mailing list for this.  However,
> it may take us a while to review patches; there aren't very many
> reviewers.  If you don't get a response within a week, then please
> post a 'ping' patch.
> 
> Your work is more likely to be reviewed if you post it as a multi-file
> patch which can be applied by running 'patch -p0 < foo.patch' in the
> top-level source directory.  Unified diffs (diff -u) seem to be the
> preferred format.
> 
> Your embed.mt file says:
> 
>     OOLIB_PATH=../../sim_lib/oolib_install
>     TDEPFILES= score-tdep.o 
>     SIM_OBS= remote-sim.o
>     TM_CLIBS = -L $(OOLIB_PATH)/lib -lsc_gdb -lsc_tools -lsc_sim -
> lsc_ice -lprobe -lscore -lsocshell -lsoc -lpackages -lstdc++ -lSDL 
-lSDL_image
>     SIM= ../sim/score/libsim.a 
> 
> It looks to me as if this means that the 'score' target depends on a
> simulator located outside the GDB tree.  Is this simulator Free
> software?  Please make sure your GDB satisfies the license conditions
> explained in the COPYING file.  If you can release the simulator as
> Free software as well, that would be best.  Otherwise, you may be able
> to satisfy the license simply by building GDB without the simulator.
> 
> It seems the simulator in your post is just a stub.  We would rather
> not have stub code in GDB.
> 
> I don't see a patch to 'sim/configure.in' in your post.
> 'sim/configure' is generated automatically from configure.in using
> autoconf.  Patches should generally not include changes to generated
> files, like 'configure', because they can be large.
> 
> I have some comments on score-tdep.c, but let's get the above issues
> sorted out first.
> 
> Finally, I don't know how Joel Brobecker, our release manager, feels
> about including new ports this late in the process.  On the one hand,
> if the port is self-contained, it is unlikely to break other code.  On
> the other hand, we have already produced our first release candidate.
> I'll leave the decision to him.
> 
> Thanks for posting this port!

Hi Jim,

Thanks for your detailed explanation! I still have some questions.

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.

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.

Only in ../gdb-6.5-score/gdb/config: score
diff -r -u ./gdb/configure.tgt ../gdb-6.5-score/gdb/configure.tgt
--- ./gdb/configure.tgt 2006-11-22 17:31:03.000000000 +0800
+++ ../gdb-6.5-score/gdb/configure.tgt  2006-12-06 11:53:23.000000000 
+0800
@@ -21,6 +21,7 @@
 m88*)          gdb_target_cpu=m88k ;;
 mips*)         gdb_target_cpu=mips ;;
 powerpc*)      gdb_target_cpu=powerpc ;;
+score*)            gdb_target_cpu=score ;;
 sparc*)            gdb_target_cpu=sparc ;;
 thumb*)            gdb_target_cpu=arm ;;
 s390*)         gdb_target_cpu=s390 ;;
@@ -174,6 +175,7 @@
 rs6000-*-aix4*)        gdb_target=aix4 ;;
 rs6000-*-*)        gdb_target=rs6000 ;;
 
+score-*-*)     gdb_target=embed ;;
 s390*-*-*)     gdb_target=s390
            build_gdbserver=yes
            ;; 
Only in ../gdb-6.5-score/gdb: score-tdep.c
Only in ../gdb-6.5-score/gdb: score-tdep.h



Best regards,
Qinwei
Mail  qinwei@sunnorth.com.cn
Phone +86-010-62981668-2708
Fax   +86-010-62985972


[-- Attachment #2: Score_GDB_Patch_NoSim.tar.gz --]
[-- Type: application/octet-stream, Size: 8452 bytes --]

Re: [patch] add target Score to GDB

[Jim Blandy]

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.