Re: [PATCH] gdb: fix xtensa build with custom overlay

[Pedro Alves <palves@redhat.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