Re: please explain some terms!

[Elena Zannoni <ezannoni@cygnus.com>]

Eli Zaretskii writes:
 > > Date: Sun, 20 Aug 2000 11:17:57 -0700 (PDT)
 > > From: Elena Zannoni <ezannoni@cygnus.com>
 > >  > 
 > >  > 1) Could someone please explain the meaning of the word 'flathead',
 > >  > found in gdbmi.texinfo?
 > > 
 > > Hmm...., er,.... Flathead is a fish. This was the internal name we
 > > gave to the GDB MI project. :-)
 > 
 > Does that mean that we should now replace all occurences of "flathead"
 > in gdbmi.texinfo with "GDB/MI"?

Yes, that would be good.

Elena
From Peter.Schauer@regent.e-technik.tu-muenchen.de Mon Aug 21 10:11:00 2000
From: "Peter.Schauer" <Peter.Schauer@regent.e-technik.tu-muenchen.de>
To: benoit.millot@cstelecom.com (Benoit MILLOT)
Cc: gdb@sourceware.cygnus.com
Subject: Re: About GDB user-defined commands ?
Date: Mon, 21 Aug 2000 10:11:00 -0000
Message-id: <200008211711.TAA15504@reisser.regent.e-technik.tu-muenchen.de>
References: <39A130C9.9AE39484@cstelecom.com>
X-SW-Source: 2000-08/msg00095.html
Content-length: 1204

Try:

define dm
set var $taddr = $arg0
set var $tsize = $arg1
while $tsize != 0
   if $tsize >= 10
     monitor dm $taddr $tsize
     set var $taddr = $taddr + 10
     set var $tsize = $tsize - 10
   else
     monitor dm $taddr $tsize
     set var $tsize = 0
   end
end
end

> Hello,
> 
> I want to develop a user-defined command for my own monitor
> which i have already implemented into gdb with nomitor ops..
> 
> Can i use a new variable? (answear seems to be NO)
> Can i make operation (addition, ...) with input argument (arg0 ...)?
> 
> example:
> user defined command dm :
> 
> dm $arg0 $arg1
> 
> while $arg0!=3D0
>    if $arg1>=3D10
>      monitor dm $arg0 $arg1
>      $arg1 =3D $arg1 -10
>      $arg0 =3D $arg0 +10
>    else
>       monitor dm $arg0 $arg1
>    end
> 
> I try this but it doesn't work and lines with $xxx =3D $ xxx +  xxx
> disappear after the first exec.
> message : No symbol in cuurent context
> 
> With line:     SET $arg0 =3D $arg0 +10
>                    Left operand of assignement is not a Lvalue
> 
> Any ides will be appreciated.
> Thanks.
> 
>                                             Beno=EEt
> 
> 
> 


-- 
Peter Schauer			pes@regent.e-technik.tu-muenchen.de
From jtc@redback.com Mon Aug 21 11:36:00 2000
From: jtc@redback.com (J.T. Conklin)
To: gdb@sourceware.cygnus.com
Subject: questions about immediate_quit...
Date: Mon, 21 Aug 2000 11:36:00 -0000
Message-id: <5mbsyma2cx.fsf@jtc.redback.com>
X-SW-Source: 2000-08/msg00096.html
Content-length: 1896

I found the following code in dcache_peek_byte():

    immediate_quit++;
    while (done < LINE_SIZE)
      {
        int try = 
        (*dcache->read_memory)
        (db->addr + done,
         db->data + done,
         LINE_SIZE - done);
        if (try == 0)
          return 0; 
        done += try;  
      }
    immediate_quit--;

Even after reading the comment describing immediate_quit in utils.c,
I'm still a bit puzzled.

* In the above code fragment, immediate quit is incremented before the
  read.  But it is only decremented if the read succeeds.  This would 
  appear to be an obvious bug.

* From the aforementioned comment, it seems that the dcache is at too
  high of a level to bother with immediate_quit.  If setting/reset it
  is necessary, it should be done in the target i/o functions.

* Examination of various target bits, reveals that in most cases
  immediate_quit is set and reset there.  However:

  - in some cases, instead of incrementing and decrementing immediate_quit,
    they are set to 1 and 0.

  - in other cases, the value of immediate_quit is saved in old_immediate_quit
    then set to 1, and finally set back to the saved value.

  The first case potentially loses when such calls are nested, as they
  are with the dcache enabled.  The second works fine, but I see a
  value in using only one idiom throughout the gdb sources.

In conclusion, I think the code touching immediate_quit in dcache.c is
unnecessary, and I'll remove it in my next set of commits.

I also think we should remove all assignments of 0/1 to immediate_quit
and replace them with increments/decrements so that it nests properly.
I think this is important even in code paths that will never nest, as
any occurance in the code may be used as a template by a future
contributor.  I prefer good examples without gotchas...

Thoughts?

        --jtc

-- 
J.T. Conklin
RedBack Networks
From dave@hiauly1.hia.nrc.ca Mon Aug 21 11:58:00 2000
From: "John David Anglin" <dave@hiauly1.hia.nrc.ca>
To: binutils@sourceware.cygnus.com, gdb@sourceware.cygnus.com
Subject: VAX PC RELATIVE JMP: gas and gdb perform incorrect sign extension
Date: Mon, 21 Aug 2000 11:58:00 -0000
Message-id: <200008211858.OAA02260@hiauly1.hia.nrc.ca>
X-SW-Source: 2000-08/msg00097.html
Content-length: 1257

In trying to build the current cvs version of gcc, I discovered an
obviously long standing bug in the treatment of long pc relative
branches on the vax.  The following code snippet from expand_expr
is incorrectly assembled by gas:

		tstl	r9
		jeql	L2956
		clrl	-(sp)

L2956 is more than 32K bytes back in the code.  After linking, I
see the following with adb:

		tstl	r9
		bneq	0xb4f06
		jmp	0xbf867	; wrong location
0xb4f06:	clrl	-(sp)

The `jmp' actually goes to 0xbf867, so I believe the adb disassembly.
However, when I look with gdb, I get:

                tstl    r9
		bneq    0xb4f06
		jmp     0xaf867 ; location of L2956
0xb4f06:        clrl    -(sp)

The hex value of the pc relative address is 0xa961 (0xb4f06 + 0xa961 =
0xbf867).  However, gas and gdb seem to think that the vax will sign
extend the word 0xa961 to the long word 0xffffa961 (0xb4f06 + 0xffffa961 =
0xaf867).  This is clearly wrong.  The correct offset is 0xffffa961.

The error is present in expr.o, so it is not the linker which causes it.
I am looking at the binutils code.  Suggestions on where to look are welcome.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)
From Stephane.Carrez@worldnet.fr Mon Aug 21 13:09:00 2000
From: Stephane Carrez <Stephane.Carrez@worldnet.fr>
To: gdb@sourceware.cygnus.com
Subject: New xxx_register gdb-arch function vs pseudo register
Date: Mon, 21 Aug 2000 13:09:00 -0000
Message-id: <39A1A9AE.E33767A3@worldnet.fr>
X-SW-Source: 2000-08/msg00098.html
Content-length: 2311

Hi!

I'm trying to fix the support for registers in the 68hc11 port. I have reached
a problem or a limitation in GDB. I have several ways to fix that and I want
to have your opinions.

The 68HC11 has only 6 real hard registers but only 3 of them can really be
used by GCC.  Since that's too small, GCC uses several soft registers.
Soft registers are in fact memory locations.  Gcc, GDB-core and the GDB simulator
do not know that.

I would like to translate the read/write of the soft registers into a
read/write of the corresponding memory location (whose address is obtained 
by looking at the symbol table). For this, I have two ways:

1/ Change 'gdb/regcache.c' to be able to override the 'target_fetch_registers()'
   and 'target_store_registers()' with a GDB multi-arch function.

   In that case, the 68hc11-tdep file is able to override the default,
   translate the fetch/store into a memory read/write or call the normal
   'target_xxx_registers()'.

   Pros: Easy to do, less changes, homogeneous with pseudo register support
   Cons: New multi-arch functions.

2/ Try to use the pseudo registers framework.
   The problem here is that the soft registers are not aliases to other
   registers (nor combination of them).  There are several places in GDB-core
   where we only take into account the NUM_REGS and not NUM_REGS+PSEUDO_REGS.

   For example, the frame structure must handle the saved registers but
   it ignores the PSEUDO_REGS.  If I want to use the pseudo registers framework,
   it will not work because the soft registers can be saved on the stack.

   There are a few places like this which must be fixed.

   Pros: No new multi-arch function, may be fix some PSEUDO_REGS support (not sure)
   Cons: More complex, may change the semantics of PSEUDO_REGS


I've implemented solution 1 in gdb 5.0 (but without multi-arch, just macros).

What do you think?

Thanks,
	Stephane

-----------------------------------------------------------------------
         Home                               Office
E-mail: stcarrez@worldnet.fr               Stephane.Carrez@sun.com
WWW:    http://home.worldnet.fr/stcarrez   http://www.sun.com
Mail:   17, rue Foucher Lepelletier        6, avenue Gustave Eiffel
        92130 Issy Les Moulineaux          78182 Saint Quentin en Yvelines
        France
From jtc@redback.com Mon Aug 21 16:03:00 2000
From: jtc@redback.com (J.T. Conklin)
To: gdb@sourceware.cygnus.com
Subject: more on immediate_quit
Date: Mon, 21 Aug 2000 16:03:00 -0000
Message-id: <5mpun28bhh.fsf@jtc.redback.com>
X-SW-Source: 2000-08/msg00099.html
Content-length: 1174

Rummaging through the GDB sources examining the use of immediate_quit,
I found another case --- this time in remote-mips.c --- where sets and
resets were unbalanced.

Am I safe in assuming that the below patch is what is intended?

        --jtc

Index: remote-mips.c
===================================================================
RCS file: /cvs/src/src/gdb/remote-mips.c,v
retrieving revision 1.8
diff -c -r1.8 remote-mips.c
*** remote-mips.c	2000/08/03 08:41:23	1.8
--- remote-mips.c	2000/08/21 22:59:17
***************
*** 609,615 ****
    char *p = string;
    int c;
  
!   immediate_quit = 1;
    while (n > 0)
      {
        c = SERIAL_READCHAR (mips_desc, 2);
--- 609,615 ----
    char *p = string;
    int c;
  
!   immediate_quit++;
    while (n > 0)
      {
        c = SERIAL_READCHAR (mips_desc, 2);
***************
*** 618,623 ****
--- 618,624 ----
  	{
  	  fprintf_unfiltered (gdb_stderr,
  		 "Failed to read %d characters from target (TIMEOUT)\n", n);
+ 	  immediate_quit--;
  	  return 0;
  	}
  
***************
*** 625,630 ****
--- 626,632 ----
        n--;
      }
  
+   immediate_quit--;
    return 1;
  }
  

-- 
J.T. Conklin
RedBack Networks
From toddpw@windriver.com Mon Aug 21 21:21:00 2000
From: Todd Whitesel <toddpw@windriver.com>
To: jtc@redback.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: questions about immediate_quit...
Date: Mon, 21 Aug 2000 21:21:00 -0000
Message-id: <200008220421.VAA05220@alabama.wrs.com>
References: <5mbsyma2cx.fsf@jtc.redback.com>
X-SW-Source: 2000-08/msg00100.html
Content-length: 361

> Thoughts?

Consistent usage of global variables is a worthy cause.

The decl should also have a stern comment next to it explaining how the
variable is to be used, so people have no excuse when they do it wrong.
(This is why fixing the bogus uses is important, so they cannot complain
"but foo.c did it that way"...)

-- 
Todd Whitesel
toddpw @ windriver.com
From sashang@hotmail.com Tue Aug 22 03:07:00 2000
From: "Sashan Govender" <sashang@hotmail.com>
To: gdb@sourceware.cygnus.com
Subject: The debuggee's output
Date: Tue, 22 Aug 2000 03:07:00 -0000
Message-id: <F1196SntxdOGCJLgRkQ00002e09@hotmail.com>
X-SW-Source: 2000-08/msg00101.html
Content-length: 412

I've been debugging gdb5 with gdb5 in an attempt to figure out how it works 
and, more specifically, how gdb handles output from the inferior/debuggee. I 
can't find the functions that take care of this. Please could some one 
explain how it works.

Thanks

Sashan
________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com