headers
xingxing pan | 3 May 2010 07:27
Picon

In the NONSTOP implementation why dose gdb use register r0 and r1 as temp registers for rn and rd ?

hey guys, I'm porting NONSTOP to an ARM similar architechure. I found
the following comments in the source.

Instruction is of form:
<op><cond> rd, [rn,] #imm
Rewrite as:
Preparation:
tmp1, tmp2 <- r0,r1
r0,r1 <- rd,rn
Insn: <op><cond> r0,r1 #imm
Cleanup: rd <- r0; r0<-tmp1;r1<-tmp2

why dose gdb use register r0 and r1? why not use rd and rn directly?
Thank you!
Permalink | Reply | 2 comments |
headers
Klaus Rudolph | 3 May 2010 12:03
Picon
Picon

pthread on powerpc, gdb 7.1

Hi all,

I actually try to use threading on a powerpc-unknown-linux-gnu.

But in gdb, there I see only the starting thread. My gdb session looks like this:

GNU DDD 3.3.12 (i486-pc-linux-gnu), by Dorothea Lütkehaus and Andreas Zeller.
Copyright © 1995-1999 Technische Universität Braunschweig, Germany.
Copyright © 1999-2001 Universität Passau, Germany.
Copyright © 2001 Universität des Saarlandes, Germany.
Copyright © 2001-2004 Free Software Foundation, Inc.
Reading symbols from /home/krud/test/flexes_test/go...done.
(gdb) set solib-absolute-prefix /opt/powerpc-unknown-linux-gnu/powerpc-unknown-linux-gnu
(gdb) target remote flexes2:3000
0x3000f0f0 in _start () from /opt/powerpc-unknown-linux-gnu/powerpc-unknown-linux-gnu/lib/ld.so.1
(gdb) cont

Program received signal SIG32, Real-time event 32.
0x0fc919d8 in ?? ()
(gdb) cont

Program received signal SIG32, Real-time event 32.
0x0fc919d8 in ?? ()
(gdb) cont

Program received signal SIG32, Real-time event 32.
0x0fc919d8 in ?? ()
(gdb) cont
^C
Program received signal SIGINT, Interrupt.
(Continue reading)

Permalink | Reply | 0 comments |
headers
xingxing pan | 3 May 2010 16:16
Picon

Re: In the NONSTOP implementation why dose gdb use register r0 and r1 as temp registers for rn and rd ?

Can anyone help?

2010/5/3 xingxing pan <forandom <at> gmail.com>:
> hey guys, I'm porting NONSTOP to an ARM similar architechure. I found
> the following comments in the source.
>
> Instruction is of form:
> <op><cond> rd, [rn,] #imm
> Rewrite as:
> Preparation:
> tmp1, tmp2 <- r0,r1
> r0,r1 <- rd,rn
> Insn: <op><cond> r0,r1 #imm
> Cleanup: rd <- r0; r0<-tmp1;r1<-tmp2
>
> why dose gdb use register r0 and r1? why not use rd and rn directly?
> Thank you!
>
Permalink | Reply | 0 comments |
headers
Daniel Jacobowitz | 3 May 2010 17:58

Re: In the NONSTOP implementation why dose gdb use register r0 and r1 as temp registers for rn and rd ?

On Mon, May 03, 2010 at 01:27:53PM +0800, xingxing pan wrote:
> hey guys, I'm porting NONSTOP to an ARM similar architechure. I found
> the following comments in the source.
> 
> Instruction is of form:
> <op><cond> rd, [rn,] #imm
> Rewrite as:
> Preparation:
> tmp1, tmp2 <- r0,r1
> r0,r1 <- rd,rn
> Insn: <op><cond> r0,r1 #imm
> Cleanup: rd <- r0; r0<-tmp1;r1<-tmp2
> 
> why dose gdb use register r0 and r1? why not use rd and rn directly?
> Thank you!

It was simpler to always use the same registers.  That way you don't
have to worry about, for instance, which registers to save and restore
or whether rd and rn overlap.  You could do it either way.

--

-- 
Daniel Jacobowitz
CodeSourcery
Permalink | Reply | 0 comments |
headers
Hui Zhu | 4 May 2010 04:44
Picon
Gravatar

Re: [Discussion/Prec] The record speed up plan (Make speed like without prec)

On Sat, May 1, 2010 at 01:52, Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> > From: Hui Zhu <teawater <at> gmail.com>
> > Date: Fri, 30 Apr 2010 21:23:20 +0800
> > Cc: Michael Snyder <msnyder <at> vmware.com>
> >
> > But lucky for us that insns exec rules we know.  So most of insns
> > (There a some special, I will talk it later), if we have the a
> > inferior value(memory and reg), we can get the each value of next
> > insn.
>
> I don't see how you can do that, unless you first read the entire
> memory of the inferior.  Otherwise, when an instruction references
> some address, how do you know what value is stored at that address?
>

You mean before or after the insn?

For the before, we do something like fork to record all of them.
For the after, as my insns knowledge most of them can be got follow
the rules.  A lot of simualtor do something like it.

> Also, what do you do with features such as shared memory, where the
> value at a given address can change beyond control of the current
> inferior, and change the result of some instruction which references
> that address?

Agree, but we can give up of them like we give up the released memory now.

>
(Continue reading)

Permalink | Reply | 3 comments |
headers
Hui Zhu | 4 May 2010 04:46
Picon
Gravatar

Re: [Discussion/Prec] The record speed up plan (Make speed like without prec)

On Sat, May 1, 2010 at 11:12, paawan oza <paawan1982 <at> yahoo.com> wrote:
> Hi,
>
> please find my analysis below.
>
>>> the first thing is, how can we rely on recording volatile memory locations. infact is is even problem
with curent prec, as the moment w are going to record next insn and volatile locations are changed then ?
>
>>> another point as Eli suggested, share memory, shared semaphores in short memory which we do not have
control over at a particular time.
>
>>> we dont know how big is the process, and we try to record everything from the beginning, and we use memory
(are we going to come up with file concept for prec info !! ), then we exhaust virtuall address space may be,
and use may not need that much of prec also.
>
>>>  currently we have not talkd to kernel guys to provide kernel support for reversible debigging, which
should essentially support reversible debugging of signals, I/O and many more primitive things, I am not
sure how this model will fit over there because there may be many asynchronous events we might want to play
it reverse.

I still didn't find some thing need kernel do.
I need inferior stop on special insn like rdtsc, but looks x86 cpu
doesn't support it.

Thanks,
Hui

>
> Regards,
> Oza.
(Continue reading)

Permalink | Reply | 0 comments |
headers
xingxing pan | 4 May 2010 10:55
Picon

A question about All-stop and Non-stop

Dose GDB in the All-stop mode has the same problem as in the Non-stop
mode when continues over a breakpoint instruction?

When GDB continues over a breakpoint instruction in the Non-stop mode,
 replacing the breakpoint instruction with the original instruction
may cause the other running threads can't hit the breakpoint. That's
why GDB needs the displaced instructions. But what about the All-stop
mode, dose GDB has the same problem in this mode?

If it does, how dose GDB solve the problem? It seems there's no trick
like the displaced instructions before Non-stop's debut.

Can anyone help?

Thank you!
Permalink | Reply | 2 comments |
headers
Pedro Alves | 4 May 2010 11:08

Re: A question about All-stop and Non-stop

On Tuesday 04 May 2010 09:55:16, xingxing pan wrote:
> Dose GDB in the All-stop mode has the same problem as in the Non-stop
> mode when continues over a breakpoint instruction?
> 
> When GDB continues over a breakpoint instruction in the Non-stop mode,
>  replacing the breakpoint instruction with the original instruction
> may cause the other running threads can't hit the breakpoint. That's
> why GDB needs the displaced instructions. 

That's only one way to solve that problem.  An efficient one though.

Another way is to pause all threads, remove breakpoints, single-step
the thread of interest, reinsert breakpoints, resume all threads again.

(This is what linux x86 gdbserver presently does to step over its
own internal breakpoints (breakpoints gdb doesn't know about), even
in non-stop mode.)

> But what about the All-stop
> mode, dose GDB has the same problem in this mode?
> If it does, how dose GDB solve the problem? It seems there's no trick
> like the displaced instructions before Non-stop's debut.

No.  It does the "pause all threads, remove breakpoints, single-step
the thread of interest, reinsert breakpoints, resume all threads again"
dance.  The "pause all threads" is implicit in all-stop, and so
all-threads-stopped is the state you start with anyway.

--

-- 
Pedro Alves
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Koning | 4 May 2010 14:15
Picon
Favicon

iconv without "wchar_t" as a conversion name

NetBSD has iconv support, essentially the same as in glibc, with one
crucial difference that messes up GDB.

In gdb_wchar.h, INTERMEDIATE_ENCODING is hardcoded as "wchar_t" and in
charset.c iconv_open() is called with INTERMEDIATE_ENCODING as the "to"
format.

As it happens, the NetBSD implementation of iconf does not list
"wchar_t" as a format it knows, though it does have a very long list of
supported formats that looks otherwise quite similar to what iconv on,
say, Linux supports.

I assume "wchar_t" means "whatever character format is the native
encoding of a wchar_t data type".  If so, it looks like "ucs-4" would be
a valid replacement, since wchar_t maps to int on NetBSD.  This suggest
that INTERMEDIATE_ENCODING should be determined by configure instead of
being hardcoded.

Does this make sense?  I can work on a patch, though hints on how to do
this in configure would be welcome since I'm a beginner in that space.

	paul
Permalink | Reply | 1 comment |
headers
Pierre Muller | 4 May 2010 15:14
Picon

RE: iconv without "wchar_t" as a conversion name

  I already tried to propose a patch going in the direction you
indicate, but the replies were not very positive...

See
http://sourceware.org/ml/gdb-patches/2010-04/msg00719.html

Pierre Muller
Pascal language support maintainer for GDB

> -----Message d'origine-----
> De : gdb-owner <at> sourceware.org [mailto:gdb-owner <at> sourceware.org] De la
> part de Paul Koning
> Envoyé : Tuesday, May 04, 2010 2:16 PM
> À : gdb <at> sourceware.org
> Objet : iconv without "wchar_t" as a conversion name
> 
> NetBSD has iconv support, essentially the same as in glibc, with one
> crucial difference that messes up GDB.
> 
> In gdb_wchar.h, INTERMEDIATE_ENCODING is hardcoded as "wchar_t" and in
> charset.c iconv_open() is called with INTERMEDIATE_ENCODING as the "to"
> format.
> 
> As it happens, the NetBSD implementation of iconf does not list
> "wchar_t" as a format it knows, though it does have a very long list of
> supported formats that looks otherwise quite similar to what iconv on,
> say, Linux supports.
> 
> I assume "wchar_t" means "whatever character format is the native
> encoding of a wchar_t data type".  If so, it looks like "ucs-4" would
(Continue reading)

Permalink | Reply | 0 comments |

Gmane