I just wanted to chime in and say that the ability to run the leon BSPs in gdb/sis will be fantastic!
Thanks, Alan On 11/14/14 1:50 PM, "Jiri Gaisler" <j...@gaisler.se> wrote: > > >On 11/14/2014 04:18 PM, Joel Sherrill wrote: >> >> On 11/14/2014 5:27 AM, Jiri Gaisler wrote: >>> >>> On 11/14/2014 02:34 AM, Chris Johns wrote: >>>> On 14/11/2014 9:12 am, Jiri Gaisler wrote: >>>>> What is the procedure to add gdb patches to RBS? >>>>> >>>> Patches are first accepted by the RTEMS Project as the definition of >>>>the tools belongs to the project and tool packagers, ie the RSB, need >>>>to adopt that definition to get a project tick. Patches should be >>>>posted upstream where possible and then referenced from there. If the >>>> upstream does not have a suitable method to reference patches we can >>>>add them to the rtems-tools.git repo under the tools directory. There >>>>are specific cases such as the openrisc tools where a specific github >>>>instance is referenced as we have a positive undertaking from that >>>> community the tools are being merged upstream. Examples of upstream >>>>patch referencing is qemu and patchworks. >>>> >>>> I do not see a patch management system for gdb. There was talk back >>>>in April of this year of gdb using patchworks and then something else >>>>however it seems to have died out. >>>> >>>>> I have a few patches that fixes the erc32 simulator and also >>>>> add support for leon2 and leon3. This would allow us to drop >>>>> the sis bsp, and also to test the leon2 and leon3 bsp's with >>>>> sis. >>>> Excellent. I suggest you provide git patches for the rtems-tools.git >>>>repo to add the patches and then provide RSB patches for the sparc gdb >>>>build to use them. There are specific sparc patches already present >>>>which need updating as they are currently stopping us moving off >>>>gdb-7.7. >>> The latest stable gdb version is 7.8.1, while the git head is at >>>7.8.50.20141112-cvs . >>> Should we switch to gdb-7.8.1 or stay at 7.7? It does not really >>>matter to me which >>> one. The existing sparc gdb patch for 7.7 is merged into my patches as >>>I had to >>> rework it a bit. >>> >>> I will try to push my patches upstream to gdb but I suspect it will >>>take >>> while before the are accepted, as they are quite large. >> It may take a while but realistically the only people who care about the >> sparc simulator are RTEMS folks and AdaCore. And you are certainly >> to be trusted for the patches. >> >> Submit them. And help the RSB switch to using all the newer patches. >> Then we can get some test time on them. That's what the gdb folks >> will want to hear. >> >> We can move rtems sparc GDB to whereever it needs to be but the >> gdb head is better for submissions and we should base the RSB >> version on a release. > > >OK, gdb-7.8.1 was released only two weeks ago so I will use this version >for RBS. > >I have found another interesting patch for sparc (pointed out by >Sebastian I believe). It fixes the problem of 'can't compute CFA', >and allows local variables to be printed properly. The patch is >listed below. Is there any reason why we shouldn't add this patch >to RBS? It only affects the sparc port so it should not have any >side-effects on other targets. Without it, debugging with gdb is >seriously limited for RTEMS sparc targets ... > > > >diff --git a/gdb/sparc-tdep.c b/gdb/sparc-tdep.c >index 7eb3b18..b26c128 100644 >--- a/gdb/sparc-tdep.c >+++ b/gdb/sparc-tdep.c >@@ -1732,6 +1732,8 @@ sparc32_gdbarch_init (struct gdbarch_info info, >struct gdbarch_list > /* Hook in ABI-specific overrides, if they have been registered. */ > gdbarch_init_osabi (info, gdbarch); > >+ dwarf2_append_unwinders (gdbarch); /* DWARF CFI frame unwinder */ >+ > frame_unwind_append_unwinder (gdbarch, &sparc32_frame_unwind); > > /* If we have register sets, enable the generic core file support. */ > >_______________________________________________ >devel mailing list >devel@rtems.org >http://lists.rtems.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
