This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] gdb: fix xtensa build with custom overlay
- From: Pedro Alves <palves at redhat dot com>
- To: Max Filippov <jcmvbkbc at gmail dot com>
- Cc: gdb-patches at sourceware dot org, Maxim Grigoriev <maxim2405 at gmail dot com>, Woody LaRue <larue at cadence dot com>, Marc Gauthier <marc at cadence dot com>, "linux-xtensa at linux-xtensa dot org" <linux-xtensa at linux-xtensa dot org>, Baruch Siach <baruch at tkos dot co dot il>
- Date: Fri, 17 Apr 2015 18:24:19 +0100
- Subject: Re: [PATCH] gdb: fix xtensa build with custom overlay
- Authentication-results: sourceware.org; auth=none
- References: <1429287116-20216-1-git-send-email-jcmvbkbc at gmail dot com> <55313315 dot 1010203 at redhat dot com> <CAMo8BfK_Z0uJYT1c8rkyZsxkXqWWxs6Cpb67aapi_cVj8rn9pg at mail dot gmail dot com>
On 04/17/2015 05:45 PM, Max Filippov wrote:
> On Fri, Apr 17, 2015 at 7:21 PM, Pedro Alves <palves@redhat.com> wrote:
>> On 04/17/2015 05:11 PM, Max Filippov wrote:
>>> The commit 14e361d7aa3bbd8601b0457ee8558344e444c651 ("xtensa-config.c:
>>> missing defs.h include") fixed the build of default xtensa configuration
>>> by including defs.h in the beginning of xtensa-config.c. Unfortunately
>>> this fix doesn't work when gdb is configured for another xtensa core, as
>>> the file xtensa-config.c is a part of configuration overlay and it gets
>>> overwritten. To fix the build for all existing configurations include
>>> defs.h into gdb/xtensa-tdep.h, where the issue (reference to undeclared
>>> uint32_t) actually is.
>>
>> Hmm, I think that's news to me. Can you please expand a bit
>> on why is this mechanism necessary?
>
> xtensa cores may have greatly varying register and instruction sets,
> depending on options configured at processor creation time. So parts
> of gdb that deal with registers and instructions are generated during
> processor build and need to be replaced in the gdb source code to
> produce gdb that can work with a particular xtensa core.
>
>> In any case, that mechanism must already by outputting:
>>
>> #include "xtensa-config.h"
>> #include "xtensa-tdep.h"
>>
>> Just make it output #include "defs.h" as well?
>
> Yes, that can be done for the newly generated files, but there are existing
> configuration overlays which we need to patch in this case. It can be done,
> it's just much more changes.
I don't know about much more changes. We really shouldn't promise not to
break out-of-tree changes. The point is this is quite brittle, and I think as
is, the onus should be on you to keep it working. Nothing tells us that we
might want or need to do an across-the-tree change that breaks all this. For
example, for the ongoing C++ conversion. It seems that the best solution
would be to design a mechanism to load this information into gdb dynamically,
either through the xml target description mechanism, or through some new Python
hook that reads an xtensa-specific description file.
Thanks,
Pedro Alves