RE: examining remote core dumps; MT support for attach;

RE: examining remote core dumps; MT support for attach;

[nak26]

>> 1. Is it possible to examine a core file on a remote machine, in the cases,
>> where fetching the core is undesirable due to the thinness of the pipe.
>
>This is not supported.

Can anybody think of another way of doing that (not involving gdbserver)?

--Nik

Re: examining remote core dumps; MT support for attach;

[Kevin Buettner]

On Jun 12,  4:17pm, nak26 wrote:

> >> 1. Is it possible to examine a core file on a remote machine, in the cases,
> >> where fetching the core is undesirable due to the thinness of the pipe.
> >
> >This is not supported.
> 
> Can anybody think of another way of doing that (not involving gdbserver)?

Either copy the file to the host or use some sort of remote filesystem
mount (e.g. NFS) to get at the core file.

I have a feeling that this isn't exactly what you wanted to hear though...

Kevin

RE: examining remote core dumps; MT support for attach;

[nak26]

>
>nak26, do you have an FSF assignment?
>
>Andrew
>

No...don't know what that means either
Cheers,
--Nik

RE: examining remote core dumps; MT support for attach;

[nak26]

>> How hard would it be to add support for that? I can give it a try, but 
would
>> need some guidance...
>
>I have no idea how you would do it.  You'd have to transfer essentially
>the same info anyway.  Or port gdbserver to have a "core file" target
>but I don't know how well that would work.

What do you mean by "Or port gdbserver to have a "core file" target
but I don't know how well that would work"?

>> I saw a PREPARE_TO_PROCEED patch beeing mentioned in some of the posts. In
>> which cases it heeds to be applied?
>
>You'll probably never hit it unless you manually use the "thread"
>command to switch threads and then single-step the new thread.

In case I need it, where can I get it from?

Thanks,
--Nik

Re: examining remote core dumps; MT support for attach;

[Daniel Jacobowitz]

On Thu, Jun 12, 2003 at 05:17:03PM -0400, nak26 wrote:
> >> How hard would it be to add support for that? I can give it a try, but 
> would
> >> need some guidance...
> >
> >I have no idea how you would do it.  You'd have to transfer essentially
> >the same info anyway.  Or port gdbserver to have a "core file" target
> >but I don't know how well that would work.
> 
> What do you mean by "Or port gdbserver to have a "core file" target
> but I don't know how well that would work"?

Allow gdbserver to read from a core file instead of a running process. 
It would be tricky; you'll have to figure out how to do it yourself.

> >> I saw a PREPARE_TO_PROCEED patch beeing mentioned in some of the posts. In
> >> which cases it heeds to be applied?
> >
> >You'll probably never hit it unless you manually use the "thread"
> >command to switch threads and then single-step the new thread.
> 
> In case I need it, where can I get it from?

The list archives.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: examining remote core dumps; MT support for attach;

[Andrew Cagney]

> On Thu, Jun 12, 2003 at 05:17:03PM -0400, nak26 wrote:
> 
>> >> How hard would it be to add support for that? I can give it a try, but 
> 
>> would
> 
>> >> need some guidance...
> 
>> >
>> >I have no idea how you would do it.  You'd have to transfer essentially
>> >the same info anyway.  Or port gdbserver to have a "core file" target
>> >but I don't know how well that would work.
> 
>> 
>> What do you mean by "Or port gdbserver to have a "core file" target
>> but I don't know how well that would work"?
> 
> 
> Allow gdbserver to read from a core file instead of a running process. 
> It would be tricky; you'll have to figure out how to do it yourself.

There was a suggestion made that GDB could manipulate files on the 
remote system (mainly to get at /proc/auxv).  Such a mechanism would 
also address the core file problem.

nak26, do you have an FSF assignment?

Andrew


>> >> I saw a PREPARE_TO_PROCEED patch beeing mentioned in some of the posts. In
>> >> which cases it heeds to be applied?
> 
>> >
>> >You'll probably never hit it unless you manually use the "thread"
>> >command to switch threads and then single-step the new thread.
> 
>> 
>> In case I need it, where can I get it from?
> 
> 
> The list archives.
> 
> -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer 

Re: examining remote core dumps; MT support for attach;

[Daniel Jacobowitz]

On Fri, Jun 13, 2003 at 09:31:23AM -0400, Andrew Cagney wrote:
> >On Thu, Jun 12, 2003 at 05:17:03PM -0400, nak26 wrote:
> >
> >>>> How hard would it be to add support for that? I can give it a try, but 
> >
> >>would
> >
> >>>> need some guidance...
> >
> >>>
> >>>I have no idea how you would do it.  You'd have to transfer essentially
> >>>the same info anyway.  Or port gdbserver to have a "core file" target
> >>>but I don't know how well that would work.
> >
> >>
> >>What do you mean by "Or port gdbserver to have a "core file" target
> >>but I don't know how well that would work"?
> >
> >
> >Allow gdbserver to read from a core file instead of a running process. 
> >It would be tricky; you'll have to figure out how to do it yourself.
> 
> There was a suggestion made that GDB could manipulate files on the 
> remote system (mainly to get at /proc/auxv).  Such a mechanism would 
> also address the core file problem.

This is a reasonable idea, but I think our current remote protocol is
not quite up to the task.  Let's keep it on the list along with
multiple channels (for I/O) and file upload/download...

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: examining remote core dumps; MT support for attach;

[Andrew Cagney]

> On Fri, Jun 13, 2003 at 09:31:23AM -0400, Andrew Cagney wrote:
> 
>> >On Thu, Jun 12, 2003 at 05:17:03PM -0400, nak26 wrote:
>> >
> 
>> >>>> How hard would it be to add support for that? I can give it a try, but 
> 
>> >
> 
>> >>would
> 
>> >
> 
>> >>>> need some guidance...
> 
>> >
> 
>> >>>
>> >>>I have no idea how you would do it.  You'd have to transfer essentially
>> >>>the same info anyway.  Or port gdbserver to have a "core file" target
>> >>>but I don't know how well that would work.
> 
>> >
> 
>> >>
>> >>What do you mean by "Or port gdbserver to have a "core file" target
>> >>but I don't know how well that would work"?
> 
>> >
>> >
>> >Allow gdbserver to read from a core file instead of a running process. 
>> >It would be tricky; you'll have to figure out how to do it yourself.
> 
>> 
>> There was a suggestion made that GDB could manipulate files on the 
>> remote system (mainly to get at /proc/auxv).  Such a mechanism would 
>> also address the core file problem.
> 
> 
> This is a reasonable idea, but I think our current remote protocol is
> not quite up to the task.  Let's keep it on the list along with
> multiple channels (for I/O) and file upload/download...

qPread;FILE,OFFSET,LENGTH
qPwrite:FILE,OFFSET,DATA

Andrew

RE: examining remote core dumps; MT support for attach;

[nak26]

>===== Original Message From Kevin Buettner <kevinb@redhat.com> =====
>On Jun 12,  4:17pm, nak26 wrote:
>
>> >> 1. Is it possible to examine a core file on a remote machine, in the 
cases,
>> >> where fetching the core is undesirable due to the thinness of the pipe.
>> >
>> >This is not supported.
>>
>> Can anybody think of another way of doing that (not involving gdbserver)?
>
>Either copy the file to the host or use some sort of remote filesystem
>mount (e.g. NFS) to get at the core file.
>
>I have a feeling that this isn't exactly what you wanted to hear though...
>
>Kevin

Copying is not desirable. Cross-mounting is an option.

Thanks,
--Nik

RE: examining remote core dumps; MT support for attach;

[nak26]

>>> 1. Is it possible to examine a core file on a remote machine, in the 
cases,
>> where fetching the core is undesirable due to the thinness of the pipe.
>
>This is not supported.

How hard would it be to add support for that? I can give it a try, but would 
need some guidance...

>> 2. Does the gdbserver that comes with gdb5.3 work with multithreaded apps, 
or
>> it needs to be additionally patched?
>
>It should work.

I saw a PREPARE_TO_PROCEED patch beeing mentioned in some of the posts. In 
which cases it heeds to be applied?

Thanks,
--Nik

Re: examining remote core dumps; MT support for attach;

[Daniel Jacobowitz]

On Thu, Jun 12, 2003 at 04:59:55PM -0400, nak26 wrote:
> >>> 1. Is it possible to examine a core file on a remote machine, in the 
> cases,
> >> where fetching the core is undesirable due to the thinness of the pipe.
> >
> >This is not supported.
> 
> How hard would it be to add support for that? I can give it a try, but would 
> need some guidance...

I have no idea how you would do it.  You'd have to transfer essentially
the same info anyway.  Or port gdbserver to have a "core file" target
but I don't know how well that would work.

> >> 2. Does the gdbserver that comes with gdb5.3 work with multithreaded apps, 
> or
> >> it needs to be additionally patched?
> >
> >It should work.
> 
> I saw a PREPARE_TO_PROCEED patch beeing mentioned in some of the posts. In 
> which cases it heeds to be applied?

You'll probably never hit it unless you manually use the "thread"
command to switch threads and then single-step the new thread.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

examining remote core dumps; MT support for attach;

[nak26]

Hi:

I have a few questions. Your 2cents would be greatly appreciated.

1. Is it possible to examine a core file on a remote machine, in the cases, 
where fetching the core is undesirable due to the thinness of the pipe.

2. Does the gdbserver that comes with gdb5.3 work with multithreaded apps, or 
it needs to be additionally patched?

3. Is there a patch that allows attaching a gdbserver to a multi threaded 
process?

Thanks,
--Nik

Re: examining remote core dumps; MT support for attach;

[Daniel Jacobowitz]

On Thu, Jun 12, 2003 at 04:03:15PM -0400, nak26 wrote:
> Hi:
> 
> I have a few questions. Your 2cents would be greatly appreciated.
> 
> 1. Is it possible to examine a core file on a remote machine, in the cases, 
> where fetching the core is undesirable due to the thinness of the pipe.

This is not supported.

> 2. Does the gdbserver that comes with gdb5.3 work with multithreaded apps, or 
> it needs to be additionally patched?

It should work.

> 3. Is there a patch that allows attaching a gdbserver to a multi threaded 
> process?

Not yet.  I believe someone is working on it.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer