This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: A change to the way we initialize new gdbarches


> Date: Wed, 4 Oct 2006 19:10:25 -0400
> From: Daniel Jacobowitz <drow@false.org>
> 
> I've been working on code that makes some new uses of the gdbarch switching
> machinery, based on information provided by (or guessed from) the target.
> While doing so I ran into a snag, which it turns out I can demonstrate
> clearly in current GDB.  Start an x86-64 GDB with a 64-bit file:
> 
> (gdb) show architecture
> The target architecture is set automatically (currently i386:x86-64)
> (gdb) set architecture i386
> The target architecture is assumed to be i386
> (gdb) set architecture auto
> The target architecture is set automatically (currently i386)
> 
> Oops!  We should have gone back to the file's 64-bit architecture!  This
> perhaps unintentional command has messed up the debug session and now we
> have to know to set it back to i386:x86-64.  Similarly (but exercising
> different code paths), you can do this with no file at all.  GDB will
> default to i386, and if you set it to i386:x86-64, it won't ever go back. 
> "set endian" has similar trouble.

So what exactly should "set architecture auto" do?

I think we should set the architecture to the architecture of the
loaded file, or the default architecture if there is no loaded file.
Will there always be a meaningful default architecture?  I think the
answer is yes for all "hosted" targets.  For example if I configure
with --target==mips64-openbsd, the default endianness should be
big-endian.  But for embedded targets that's not always clear I think.

> This happens because we fill in the defaults for a new architecture from the
> previously selected architecture.  These are derived properties, based on
> the user's settings (at the time), the selected file (at the time), and so
> forth.  This filling happens in two general places; in gdbarch_info_fill,
> and in tdep files in the gdbarch_init method.
> 
> Here's a proposed approach to change that.  Note: it only compiles on i386
> or x86-64.  Changing the other architectures will not be hard, but it will
> be somewhat time consuming, so I wanted to get feedback on what I've done
> so far.

Whatever we decide, I think it is necessary to have a thorough look at
architectures that don't have a fixed endian-ness (like mips).

> Instead of inheriting derived properties (like "endianness") from the
> previous architecture, only inherit primary properties (like "the endianness
> of the user's file").

I wonder whether inheriting anything from the previous architecture is
a good idea at all.

> This lets gdbarch_update_p continue to work - you can set just one
> thing in info, and then you'll get back a new architecture just like
> the previous one, but with that property changed.  One way to see
> this is that gdbarch_update_p is a "specialization" mechanism, and
> without my patches we're fine as long as we are increasing the
> specialization - but we can't decrease it.
> 
> I cached specific information from the bfd, rather than relying on the bfd
> to stay open.  This lets us continue to reuse architectures, although we're
> slightly pickier about what constitutes "similar enough for reuse" now.
> Some architectures fetch their own additional information from the bfd;
> I plan to add a new registration function that will let them record it
> in gdbarch_info, using the currently unused gdbarch_tdep_info.  Right
> now bfd_info is the only cached bit; in the future, properties read from
> the target will be cached also.

You're thinking about caching things to avoid refetching the info from
the target isn't it?  But we should invalidate that info when we
disconnect from the target.

> Another advantage of this approach is that currently the "check
> gdbarch_info, then check abfd, then check the last architecture" code is
> duplicated in each tdep file.  After this, any information which we would
> have gathered from the BFD will always be available in struct gdbarch_info
> for future architectures - I find getting this right pretty
> headache-inducing in the current setup and I expect the new version to be
> much briefer.

That'd be good.

> What do you all think?  Is this sensible, or am I moving in the wrong
> direction?

I find this particular bit of code very hard to understand, and I'm
afraid I can't answer this question right now.  Hopefully your answers
to my questions will help me judging this better.

Mark


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]