please explain some terms!

please explain some terms!

[Dmitry Sivachenko]

Hello all!

1) Could someone please explain the meaning of the word 'flathead',
found in gdbmi.texinfo?

2) What are 'mode', 'member mode', 'varying mode' and 'instance mode'
(these are Chill terms, found in gdb.texinfo).

Any help will be greatly appreciated.

Thank you in advance,
Dmitry.

Re: please explain some terms!

[Elena Zannoni]

Dmitry Sivachenko writes:
 > Hello all!
 > 
 > 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. :-)


 > 
 > 2) What are 'mode', 'member mode', 'varying mode' and 'instance mode'
 > (these are Chill terms, found in gdb.texinfo).
 > 

I don't know about these, sorry.

 > Any help will be greatly appreciated.
 > 
 > Thank you in advance,
 > Dmitry.
 > 
 > 
 > 

Elena
From kistler@cs.utexas.edu Sun Aug 20 18:27:00 2000
From: Mike Kistler <kistler@cs.utexas.edu>
To: gdb@sources.redhat.com
Subject: Just-In-Time debugging with GDB
Date: Sun, 20 Aug 2000 18:27:00 -0000
Message-id: <39A08630.7E36E60@cs.utexas.edu>
X-SW-Source: 2000-08/msg00086.html
Content-length: 1265

Hello,

I am interested in doing "just-in-time" debugging with gdb.  The basic
idea is to launch the program normally (not under the debugger), but
if an error occurs (e.g. memory protection exception), the debugger
magically launches and attaches to the program at the point of error.
The program could also cause the debugger to launch using a call to
some special procedure. This is available on other platforms and I
have used it quite a bit.  Perhaps it is also available in gdb ... if
so,
I would really appreciate a pointer to some information on it.

I have been trying to engineer a crude version of this on my own,
and it kinda works.  However, I would like to disable it if I decide
to launch the program under gdb (I don't need 2 debug sessions
for the same program!).  I thought I could determine if gdb was
already active by checking the signal handler for SIGINT.  I
figured that gdb would have installed a signal handler for this, and
thus if gdb was already running, the handler for SIGINT would
not be SIG_DFL.  Unfortunately, this is apparently not so.  Is
there some technique I can use to determine if my program is
running under the control of gdb?

Many thanks in advance to anyone that can provide guidance on
these issues.

Mike Kistler

Re: please explain some terms!

[Eli Zaretskii]

> 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"?
From ac131313@cygnus.com Sun Aug 20 23:33:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Elena Zannoni <ezannoni@cygnus.com>
Cc: Dmitry Sivachenko <dima@Chg.RU>, gdb@sources.redhat.com
Subject: Re: please explain some terms!
Date: Sun, 20 Aug 2000 23:33:00 -0000
Message-id: <39A0CBBF.81C1A6ED@cygnus.com>
References: <2818304729.20000819234724@Chg.RU> <200008201817.LAA03017@critters.cygnus.com>
X-SW-Source: 2000-08/msg00089.html
Content-length: 528

Elena Zannoni wrote:
> 
> Dmitry Sivachenko writes:
>  > Hello all!
>  >
>  > 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. :-)

Or to be more exact, this fish :-)

http://www.nre.vic.gov.au/web/root/domino/infseries/infsheet.nsf/6adff5ed78795dc64a256516001f223e/fecf011a7b088aff4a2566430022630d?OpenDocument

Flathead was originally refered to as ``headless gdb''.

	Andrew
From Don.Sharp@dddandr.octacon.co.uk Mon Aug 21 03:25:00 2000
From: Don Sharp <Don.Sharp@dddandr.octacon.co.uk>
To: gdb@sourceware.cygnus.com
Subject: gdb-5.0 on HPUX 11.00
Date: Mon, 21 Aug 2000 03:25:00 -0000
Message-id: <39A103B0.F2CD5766@dddandr.octacon.co.uk>
X-SW-Source: 2000-08/msg00091.html
Content-length: 542

Has anyone got a working gdb-5.0 implemented on HPUX 11.00 ?
I've successfully built gdb-5.0 but when attempting to use it to debug
our program we get the message

(gdb) file bin/HPUXourprogram
Reading symbols from bin/HPUXourprogram...I'm sorry, Dave, I can't do
that.  Symbol format `som' unknown.
(gdb)

We are running
HP-UX ourmachine B.11.00 U 9000/800
with gcc-2.95.2 and binutils-2.10 and configure recognizes the system as
hppa2.0w-hp-hpux11.00.

Please CC any replies to me as I am not a regular member of this list.

TIA

Don Sharp
From info@meet-electronics.com Mon Aug 21 04:14:00 2000
From: meet-electronics <info@meet-electronics.com>
To: gdb@sourceware.cygnus.com
Subject: GNU tools for Hitachi H8/300H and H8S
Date: Mon, 21 Aug 2000 04:14:00 -0000
Message-id: <3997D64C@webmail.swiss-web.com>
X-SW-Source: 2000-08/msg00092.html
Content-length: 3329

Dear Gentleman / Madam,


It is now the third time I am trying to reach someone at GNU and I am always 
getting my mail returned with the comment to send it somewhere else.
PLEASE do not tell me to send this email elsewhere. Instead, please just 
forward it to the competent person for me. THANK YOU !!
If this is the kind of support I am must expect to get from GNU, then I am 
rather scared !
(please note: I already registered to your mailing list as:
ric@meet-electronics.com)

Here's my original email, for which I am still waiting for an answer:

I am a project engineer of MEET Ltd, a HW / SW design company.
For a new project, I am for the first time considering to use GNU
development tools.
The processor that we want to use is either a H8/300H or H8S from Hitachi.

We received a CD from Hitachi, containing evaluation versions of different
development tools, among those GNU from Cygnus.

For debugging, we would like to use a ROM Monitor system, consisting of a PC
(running GDD) that connects to the target board thru a RS232 interface. I
understand that for this purpose, a special software must be first installed
on the target board's processor. I think that you call this software "STUB".

(we would like to avoid the purchase of an emulator, since this is just a
small project with a small budget).

On the Hitachi CD, I could find several "stub.c" files, however none of them
is for the H8/300H or for the H8S (but there's one, for example, for the
SH).

Since I am not very familiar with GNU tools, may I kindly ask you to answer
my following 6 (six) questions:

1.
Do "stub.c" files for the H8/300H or H8S already exist and where can we find
them ?

2.
In order to get a working version of stub software, ready to be burned in to
the target board's eprom, what amount of work do we have to expect (hours /
weeks) ? (remind that we have no experience with GNU, but we have plenty of
experience with other development tools)

3.
Is the "stub.c" file the only one that is needed, or are other files
required in order to build a complete stub software that can be burned into
the target board's eprom ? If other files are needed, which ones ?

4.
Where are the low level RS232 input/output handler routines (I could not
find them in the provided "stub" file examples) ?

5.
How/where can we tell the stub software about the memory map and other
hardware configurations (RAM location, ROM location, bus size, wait states
etc,) ?

6.
Are there already compiled versions of stub software, ready to be burned
into eprom, for example for a H8S/2345 target board (e.g. versions that use
the processor's RS232 port) ?


Thank you for your quick reply.

Regards.
R. Monleone
email: ric@meet-electronics.com
--


mmmm mmmm m        eeee         eeeee        t
mmmm mmmm mmm   e eeeeeeee    e eeeeeeee   tttt
mmmm mmmm mmmm eeee eeeeeee  eeee eeeeeee  tttt t
mmmm mmmm mmmm eeeeee eeeeee eeeeee eeeeee tttt
mmmm mmmm mmmm eeeeeeee      eeeeeeee      tttt
mmmm mmmm mmmm  eeeeeeeee     eeeeeeeee     ttt
mmmm mmmm mmmm     eeeee         eeeee       tt


MEET Electronics Ltd          Ph: ..41-91-6300270
P.O. Box                      Fx: ..41-91-6300277
6877 Coldrerio (Switzerland)

           URL:   www.meet-electronics.com
         email:   info@meet-electronics.com
--------------------------------------------------

Re: please explain some terms!

[Elena Zannoni]

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