[PATCH] RSB/gdb: upgrade sis to 2.11

[Jiri Gaisler]

On 2/4/19 10:23 AM, Sebastian Huber wrote:
> On 04/02/2019 10:16, Jiri Gaisler wrote:
>> On 2/4/19 9:02 AM, Jiri Gaisler wrote:
>>> On 2/4/19 8:00 AM, Chris Johns wrote:
>>>> On 3/2/19 8:38 pm, Jiri Gaisler wrote:
>>>>>  From 72799748f8dca595f804dcf0efd566b3a88eb36e Mon Sep 17 00:00:00 2001
>>>>> From: Jiri Gaisler<jiri at gaisler.se>
>>>>> Date: Sun, 3 Feb 2019 10:04:00 +0100
>>>>> Subject: [PATCH] gdb: upgrade sis to 2.11
>>>>>
>>>>>     * support RISC-V extension IMACFD
>>>>>     * fix broken erc32 memory controller settings
>>>>> ---
>>>> Why in this config ...
>>>>
>>>>>   .../rtems-gdb-ce73f310150418a9a1625ab60a527d959096a9e2.cfg    | 4 ++--
>>>> ... is gdb-7-1 build recipe being included ..
>>>>
>>>>>   %include %{_configdir}/gdb-7-1.cfg
>>>> ? Should this be:
>>>>
>>>> %include %{_configdir}/gdb-8-1.cfg
>>>>
>>>> ?
>>>>
>>>> Are you OK if I add this patch to:
>>>>
>>>>   https://devel.rtems.org/ticket/3460
>>>>
>>>> as an attachment so I can create `rtems-gdb-8.2.1-1.cfg`? I ask because `bfin`
>>>> is broken with gdb-8.0.1 (in the sim code) on FreeBSD 12.0-p2 ..
>>>>
>>>>   https://lists.rtems.org/pipermail/build/2019-February/001775.html
>>>>
>>>> A gdb-8.2.1 with this patch builds for the bfin plus all the other architectures
>>>> in 5/rtems-all.:)
>>>>
>>>> Note, I have not run any simulations with this patch yet.
>>> Switch to gdb-8.2.1 is fine with me, I am using gdb-head for my own development. I will check the sis patch again, I did not think it would apply to gdb-8.2.1 due to some conflicting changes to configure.tgt ...
>> A problem with gdb-8.2.1 is that it does not recognize riscv-rtems as valid target, only riscv32- or riscv64- . This has been fixed in later versions of gdb. sis for RISC-V will therefore not build with the present patch. I will update the patch for 8.2.1 and post it on the list ...
>
> We could also switch to a GDB  head version. From my experience it is a very stable project.

I would prefer a fixed gdb version, rather than tracking gdb-head. At least until I manage to merge my patches into the mainline. To make my patches less 'invasive', I'm contemplating to move them to a separate gdb target, e.g. 'target sis'. Then I will not interfere with gdb's internal simulator and I can add things like hardware watchpoints which is not on the interface to gdb's internal sims. I will see how realistic this is ...