[RFC] Changes to *_*regset functions

[RFC] Changes to *_*regset functions

[Daniel Jacobowitz]

Along with the cross-core handling, and eventually cross-thread support, I
want to multi-arch supply_gregset/fill_gregset/supply_fpregset/fill_fpregset,
and make them target rather than native functions where possible.  The issue,
of course, is that the *regset_t and *reg_t types are not available to us
when cross compiling, and attempting to make them available seems the wrong
way to go.

Given that almost every call to or definition of these functions starts by
casting its arguments anyway, I'd like to change the prototypes to the
somewhat vaguer:

extern void supply_gregset (char *gregs);
extern void supply_fpregset (char *fpregs);
extern void fill_gregset (char *gregs, int regno);
extern void fill_fpregset (char *fpregs, int regno);

It'll add a couple of casts, and remove a couple, and end up with functions
that can be safely defined in a cross debugger.

Any objection to this?

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFC] Changes to *_*regset functions

[Andrew Cagney]

> Along with the cross-core handling, and eventually cross-thread support, I
> want to multi-arch supply_gregset/fill_gregset/supply_fpregset/fill_fpregset,
> and make them target rather than native functions where possible.  The issue,
> of course, is that the *regset_t and *reg_t types are not available to us
> when cross compiling, and attempting to make them available seems the wrong
> way to go.


Do they belong in gdbarch?  gdbarch contains things that describe the 
target systems ISA, ABI, ...

Something like supply_gregset() might use gdbarch.  I don't know that it 
belongs in multi-arch.

	Andrew

Re: [RFC] Changes to *_*regset functions

[Kevin Buettner]

On Jul 13, 10:26am, Daniel Jacobowitz wrote:

> Given that almost every call to or definition of these functions starts by
> casting its arguments anyway, I'd like to change the prototypes to the
> somewhat vaguer:
> 
> extern void supply_gregset (char *gregs);
> extern void supply_fpregset (char *fpregs);
> extern void fill_gregset (char *gregs, int regno);
> extern void fill_fpregset (char *fpregs, int regno);
> 
> It'll add a couple of casts, and remove a couple, and end up with functions
> that can be safely defined in a cross debugger.
> 
> Any objection to this?

For this type of thing, I'd prefer to see void * rather than char *.

Of course, the problem with using void * is that we can now pass any
pointer type at all and the compiler won't bat an eye.  One of the
things that I learned while doing the ptid_t conversions was that
passing structs (and not pointers to structs) was incredibly useful
for catching type errors.  (Pointers to structs work okay too if your
code compiles cleanly with -Werror.)  Of course, your struct could be
defined something like this:

    struct gdb_gregset
      {
        void *gregset_ptr;	/* pointer to a chunk of memory with the
				   registers.  */
      };

Then one of your prototypes could be:
    
    extern void supply_gregset (struct gdb_gregset gregs);

Kevin

Re: [RFC] Changes to *_*regset functions

[Kevin Buettner]

On Jul 13,  2:46pm, Andrew Cagney wrote:

> > Along with the cross-core handling, and eventually cross-thread support, I
> > want to multi-arch supply_gregset/fill_gregset/supply_fpregset/fill_fpregset,
> > and make them target rather than native functions where possible.  The issue,
> > of course, is that the *regset_t and *reg_t types are not available to us
> > when cross compiling, and attempting to make them available seems the wrong
> > way to go.
> 
> 
> Do they belong in gdbarch?  gdbarch contains things that describe the 
> target systems ISA, ABI, ...
> 
> Something like supply_gregset() might use gdbarch.  I don't know that it 
> belongs in multi-arch.

For Daniel's purposes, supply_gregset() does need to be multi-arch. 
Imagine wanting to debug UnixWare, Solaris/x86, Linux, and FreeBSD
core files from a NetBSD/PPC platform.  In other words, think of the
core file format as an extension of the ABI.

Kevin

Re: [RFC] Changes to *_*regset functions

[Daniel Jacobowitz]

On Fri, Jul 13, 2001 at 12:35:13PM -0700, Kevin Buettner wrote:
> On Jul 13,  2:46pm, Andrew Cagney wrote:
> 
> > > Along with the cross-core handling, and eventually cross-thread support, I
> > > want to multi-arch supply_gregset/fill_gregset/supply_fpregset/fill_fpregset,
> > > and make them target rather than native functions where possible.  The issue,
> > > of course, is that the *regset_t and *reg_t types are not available to us
> > > when cross compiling, and attempting to make them available seems the wrong
> > > way to go.
> > 
> > 
> > Do they belong in gdbarch?  gdbarch contains things that describe the 
> > target systems ISA, ABI, ...
> > 
> > Something like supply_gregset() might use gdbarch.  I don't know that it 
> > belongs in multi-arch.
> 
> For Daniel's purposes, supply_gregset() does need to be multi-arch. 
> Imagine wanting to debug UnixWare, Solaris/x86, Linux, and FreeBSD
> core files from a NetBSD/PPC platform.  In other words, think of the
> core file format as an extension of the ABI.

Exactly what I wanted to address.  The other issue is with thread
libraries; thread_db makes calls down to supply_gregset and
fill_gregset, so if we ever share that layer between two ABIs, this
will need to happen.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFC] Changes to *_*regset functions

[Andrew Cagney]

> For Daniel's purposes, supply_gregset() does need to be multi-arch. 
> Imagine wanting to debug UnixWare, Solaris/x86, Linux, and FreeBSD
> core files from a NetBSD/PPC platform.  In other words, think of the
> core file format as an extension of the ABI.


Point taken.  I think we need to be careful here though.  To me, 
supply_gregset() is more like the DWARF2_REG_TO_REGNUM() functions then 
part of an ABI.  They provide a mapping between an external and an 
internal representation. They happen to get lumped into gdbarch because 
that is all we have at present.

It is sounding like there are three components here: ISA, ABI and this 
interface code.

	Andrew

Re: Can you point me in the right direction

[Stephen Smith]

Well, I had missed the configure.tgt file, I had figured out the *.mt *.mh *-pe.h files and was down to link errors.  I
guess I just quit to soon <sigh>

sps

Kevin Buettner wrote:

> On Jul 13, 12:32pm, Stephen Smith wrote:
>
> > I don't know if you have been following my question about a linux
> > hosted x86-pe targeted gdb.  I have posted to this mailing list and
> > didn't receive a response.
> >
> > Should I be posting to another group or should I assume that the
> > thing is not doable?
>
> You have the right group.  I would assume that no one has responded
> because either they're too busy or simply do not know the answer.
> (I'm busy and I didn't know the answer.)
>
> Anyway, I took a quick look in configure.tgt and i386-*-pe* is
> missing.  So for starters, you'll have to add one.  Then you'll have
> to add a couple of files to config/i386.  You'll need a pe.mt and
> tm-pe.h.  (I think.) Once you have those set up, do a build and see
> what's missing (link errors).  You may need to add an i386-pe-tdep.c
> file to describe your ABI...  (But you can see if one of the existing
> ones will work for you first.)
>
> Fortunately, it looks like there's an entry for bfd, so you won't
> have much work to do there.
>
> Kevin

Re: Can you point me in the right direction

[Kevin Buettner]

On Jul 13,  1:07pm, Stephen Smith wrote:

> Well, I had missed the configure.tgt file, I had figured out the
> *.mt *.mh *-pe.h files and was down to link errors.  I guess I just
> quit to soon <sigh>

You shouldn't need a *.mh file.  You might try using config/i386/embed.mt
and config/i386/tm-embed.h.  I.e, just add

i[3456]86-*-pe*)	gdb_target=embed ;;

to configure.tgt and see where that gets you.

Kevin