This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [rfc] Introduce "per-objfile" gdbarch
- From: Daniel Jacobowitz <drow at false dot org>
- To: Ulrich Weigand <uweigand at de dot ibm dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Sun, 16 Dec 2007 17:07:38 -0500
- Subject: Re: [rfc] Introduce "per-objfile" gdbarch
- References: <200712091940.lB9JeSqO019994@d12av02.megacenter.de.ibm.com>
On Sun, Dec 09, 2007 at 08:40:28PM +0100, Ulrich Weigand wrote:
> The only instances that remain are related to:
>
> - Register numbering (gdbarch_XXX_reg_to_regnum)
>
> This is somewhat of a fundamental problem: if we allow GDB register numbers
> to depend on per-target information, having symbol classes like LOC_REGISTER
> simply makes no sense, as during symbol reading the GDB register numbers
> are not really well-defined yet.
>
> This is not an issue with DWARF-2, as it always uses LOC_COMPUTED instead.
> Maybe it would be good to change the other symbol readers in a similar way?
That would work.
Another possibility would be to make the mappings independent of the
target; I've demonstrated how you can do this by making unavailable
registers have the int0 type and no name, but still have reserved
register numbers. It does simplify quite a lot.
> - dwarf2_tracepoint_var_ref calls gdbarch_virtual_frame_pointer. I guess that
> gdbarch callback really needs to be eliminated.
Jim has been, I think, working on this.
> Note that the patch makes no effort to *enforce* that the per-objfile
> gdbarch is used only for the subset of functions described above. I'm
> not sure whether we should do so (and how?), or whether this is simply
> a matter of proper documentation ...
>
> What do you think about this approach?
I like it.
--
Daniel Jacobowitz
CodeSourcery