Extending corefile.exp to handle remote targets

Extending corefile.exp to handle remote targets

[Orjan Friberg]

I'm looking at testing the core dump functionality for CRIS (remote 
target, Linux-based).  (The gcore functionality is not an option for a 
remote target, right?).

I was thinking I should extend corefile.exp to work with a remote 
target, probably adding a register restoration check, and possibly even 
unifying it with gcore.exp - or is there a reason for the difference 
between the two?  On the surface it looks like the only difference is 
how the core file is generated.

Any hints or warnings before I proceed?

-- 
Orjan Friberg
Axis Communications

Re: Extending corefile.exp to handle remote targets

[Andrew Cagney]

> I'm looking at testing the core dump functionality for CRIS (remote target, Linux-based).  (The gcore functionality is not an option for a remote target, right?).

There's also auxv.exp and, to a lesser extent, bigcore.exp.

I've actually been thinking of submitting a patch that splits auxv.exp 
in two - separately test auxv with corefile.  That way it's easier to 
differentiate between broken native and broken corefile auxv.

But what ever.

> I was thinking I should extend corefile.exp to work with a remote target, probably adding a register restoration check, and possibly even unifying it with gcore.exp - or is there a reason for the difference between the two?  On the surface it looks like the only difference is how the core file is generated.
> 
> Any hints or warnings before I proceed?

Watch out for BFD!

Writing cross core-files doesn't work because the relevant BFD code 
assumes HOST == TARGET :-(

It's been suggested that we [gdb] should instead implement our own local 
core file manipulation routines and bypass what's provided by BFD.

Andrew

Re: Extending corefile.exp to handle remote targets

[Daniel Jacobowitz]

On Thu, Aug 05, 2004 at 05:19:51PM +0200, Orjan Friberg wrote:
> I'm looking at testing the core dump functionality for CRIS (remote 
> target, Linux-based).  (The gcore functionality is not an option for a 
> remote target, right?).

Incorrect.  It doesn't work today but there's no theoretical reason
gdbserver could not handle it.

-- 
Daniel Jacobowitz

Re: Extending corefile.exp to handle remote targets

[Michael Chastain]

Orjan Friberg <orjan.friberg@axis.com> wrote:
> Any hints or warnings before I proceed?

:dumb look: I'm not fluent in this area of the test suite.

About all I can say is, if you choose to re-organize the various
core tests, separate the re-organization patches from the
"actually change stuff" patches.

Michael C

Re: Extending corefile.exp to handle remote targets

[Orjan Friberg]

Daniel Jacobowitz wrote:
> On Thu, Aug 05, 2004 at 05:19:51PM +0200, Orjan Friberg wrote:
> 
>>I'm looking at testing the core dump functionality for CRIS (remote 
>>target, Linux-based).  (The gcore functionality is not an option for a 
>>remote target, right?).
> 
> 
> Incorrect.  It doesn't work today but there's no theoretical reason
> gdbserver could not handle it.

Sorry, bad wording on my part: I meant to suggest using gcore for a 
remote target is not an option _now_ (which was the reason for wanting 
to test my core dumps another way than through gcore.exp et. al.)

-- 
Orjan Friberg
Axis Communications

Re: Extending corefile.exp to handle remote targets

[Michael Snyder]

Orjan Friberg wrote:
> Daniel Jacobowitz wrote:
> 
>> On Thu, Aug 05, 2004 at 05:19:51PM +0200, Orjan Friberg wrote:
>>
>>> I'm looking at testing the core dump functionality for CRIS (remote 
>>> target, Linux-based).  (The gcore functionality is not an option for 
>>> a remote target, right?).
>>
>>
>>
>> Incorrect.  It doesn't work today but there's no theoretical reason
>> gdbserver could not handle it.
> 
> 
> Sorry, bad wording on my part: I meant to suggest using gcore for a 
> remote target is not an option _now_ (which was the reason for wanting 
> to test my core dumps another way than through gcore.exp et. al.)

Orjan,

When I wrote the gcore stuff, I tried to leave it open to be
extended for remote targets at some later time.  It certainly
should be possible.

Michael