headers
Ananth Sowda | 1 Jul 2008 03:42
Picon

remote protocol target byte ordering question

I know that GDB remote protocol uses target byte ordering for
multi-bytes values as in register set content, memory address or
values to be written  to the target memory. I don't see where in the
GDB code this swapping from host to target byte order is done. Can
someone point to the right segment of the code? Thanks for any
pointers.
Permalink | Reply | 2 comments |
headers
Daniel Jacobowitz | 1 Jul 2008 04:14

Re: remote protocol target byte ordering question

On Mon, Jun 30, 2008 at 06:42:09PM -0700, Ananth Sowda wrote:
> I know that GDB remote protocol uses target byte ordering for
> multi-bytes values as in register set content, memory address or
> values to be written  to the target memory. I don't see where in the
> GDB code this swapping from host to target byte order is done. Can
> someone point to the right segment of the code? Thanks for any
> pointers.

Everywhere.  The gdb convention is that all buffers are in target byte
order.  For instance, follow extract_unsigned_integer.

--

-- 
Daniel Jacobowitz
CodeSourcery
Permalink | Reply | 0 comments |
headers
Justin Ferguson | 1 Jul 2008 06:40
Picon

following execve()

Hi,

What is the suggested method for following an execve() in an
application? I seem to remember I used to get a sigtrap, but not so
much anymore-- googling around I see that it looks like using tcatch
exec/cont/tbreak main is supposed to work, naturally it does not, the
break in main attempts to break in the original applications context,
and then it fails to be able to really do much of anything
(presumably) due to not properly attaching to the new process and not
being able to access it's memory. Then stack corruption occurs in the
target application, which causes gdb to just hang and requires me to
kill -9 it.

So how exactly am I supposed to do this?
Permalink | Reply | 4 comments |
headers
Vladimir Prus | 1 Jul 2008 13:37

Re: How to catch GDB crash

On Thursday 26 June 2008 03:27:58 Pedro Alves wrote:
> A Wednesday 25 June 2008 09:02:33, Dmitry Smirnov wrote:
> > Hi Pedro,
> >
> > I'll try to figure out, whether skyeye (which is remote target) supports
> > notion of thread ids or pids. Now I just suppose it does not support.
> > Nevertheless, I do not believe this is related to a crash.
> 
> Yes it is.  :-)
> 
> >
> > As I said previously, I was debugging this program (ARM code) for some time
> > previously. 
> 
> But you've certainly upgraded your GDB recently (I can tell by your log
> output on your original post).  As I said, this is a recently introduced
> regression.
> 
> I've was able to reproduce the problem, by connecting to a local
> gdbserver with a GDB with all thread support hacked out in the
> remote target.
> 
> > BTW, I've just realized that command-line interface does not use mi_*
> > interface (neither mi_on_resume nor mi_execute_command were hit) and this
> > is most likely the reason why I cannot reproduce this test case with CLI.
> >
> 
> Yes, that's exactly the reason.
> 
> Anyway, I've posted a patch that fixes the issue in your case
(Continue reading)

Permalink | Reply | 1 comment |
headers
Pedro Alves | 1 Jul 2008 13:40

Re: How to catch GDB crash

A Tuesday 01 July 2008 12:37:35, Vladimir Prus wrote:

> I think that for the time being, we can change the assert to check that
> either the program is single-threaded, or the thread is known. If the
> program is single-threaded, the the thread id is not registered, omitting
> thread-id completely seems right.
>
> I can make this change, or you have something already?
>

Please go ahead.  Thanks.

--

-- 
Pedro Alves
Permalink | Reply | 0 comments |
headers
Daniel Jacobowitz | 1 Jul 2008 14:42

Re: following execve()

On Tue, Jul 01, 2008 at 04:40:54AM +0000, Justin Ferguson wrote:
> Hi,
> 
> What is the suggested method for following an execve() in an
> application?

On what platform, with what version of GDB?

It should happen automatically with current versions of GDB on
GNU/Linux.  I believe HP/UX also.

--

-- 
Daniel Jacobowitz
CodeSourcery
Permalink | Reply | 3 comments |
headers
Michael Snyder | 1 Jul 2008 21:11

Re: remote protocol target byte ordering question

On Mon, 2008-06-30 at 18:42 -0700, Ananth Sowda wrote:
> I know that GDB remote protocol uses target byte ordering for
> multi-bytes values as in register set content, memory address or
> values to be written  to the target memory. I don't see where in the
> GDB code this swapping from host to target byte order is done. Can
> someone point to the right segment of the code? Thanks for any
> pointers.

There is a family of conversion functions whose names
begin with either "store_" or "extract_", and then a type
such as "signed_integer" or "unsigned_long", so eg.
"extract_unsigned_integer".

When you "extract" a value, you're taking it from target
format to host format, and when you "store" one you are
sending it from host format to target format.
Permalink | Reply | 0 comments |
headers
Justin Ferguson | 2 Jul 2008 00:16
Picon

Re: following execve()

Hi,

gdb 6.7.1 on x86_64 linux, it works fine so long as I dont try to
break anywhere in the new process. The hang is something to do with
signals as a sigsegv should be getting delivered thats not, I'm not
incredibly concerned about that, but I'd sure like to be able to break
in the new process.

On Tue, Jul 1, 2008 at 5:42 AM, Daniel Jacobowitz <drow <at> false.org> wrote:
> On Tue, Jul 01, 2008 at 04:40:54AM +0000, Justin Ferguson wrote:
>> Hi,
>>
>> What is the suggested method for following an execve() in an
>> application?
>
> On what platform, with what version of GDB?
>
> It should happen automatically with current versions of GDB on
> GNU/Linux.  I believe HP/UX also.
>
> --
> Daniel Jacobowitz
> CodeSourcery
>
Permalink | Reply | 2 comments |
headers
Daniel Jacobowitz | 2 Jul 2008 01:36

Re: following execve()

On Tue, Jul 01, 2008 at 03:16:31PM -0700, Justin Ferguson wrote:
> Hi,
> 
> gdb 6.7.1 on x86_64 linux, it works fine so long as I dont try to
> break anywhere in the new process. The hang is something to do with
> signals as a sigsegv should be getting delivered thats not, I'm not
> incredibly concerned about that, but I'd sure like to be able to break
> in the new process.

Try a current snapshot instead of 6.7.1 and see if that's better.

--

-- 
Daniel Jacobowitz
CodeSourcery
Permalink | Reply | 1 comment |
headers
Justin Ferguson | 2 Jul 2008 03:18
Picon

Re: following execve()

Thanks, that appears to have fixed it.

On Tue, Jul 1, 2008 at 11:36 PM, Daniel Jacobowitz <drow <at> false.org> wrote:
> On Tue, Jul 01, 2008 at 03:16:31PM -0700, Justin Ferguson wrote:
>> Hi,
>>
>> gdb 6.7.1 on x86_64 linux, it works fine so long as I dont try to
>> break anywhere in the new process. The hang is something to do with
>> signals as a sigsegv should be getting delivered thats not, I'm not
>> incredibly concerned about that, but I'd sure like to be able to break
>> in the new process.
>
> Try a current snapshot instead of 6.7.1 and see if that's better.
>
> --
> Daniel Jacobowitz
> CodeSourcery
>
Permalink | Reply | 0 comments |

Gmane