gdb patches to RBS

Fri Nov 14 18:54:37 UTC 2014

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" <jiri at 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 at rtems.org
>http://lists.rtems.org/mailman/listinfo/devel