gdb patches to RBS

[Joel Sherrill]

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.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985