On 11/14/2014 12:50 PM, Jiri Gaisler 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 ... Please include it. Being able to print local variables is important.
> > > 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. */ > -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.com On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel