Odd, ptrace_getregs

Odd, ptrace_getregs

[Daniel Berlin]

I was just generating some diffs, and noticed this:
RCS file: /cvs/src/src/gdb/configure,v
retrieving revision 1.11
diff -r1.11 configure
3737c3737
< echo "$ac_t""$gdb_cv_have_ptrace_geregs" 1>&6
---
> echo "$ac_t""$gdb_cv_have_ptrace_getregs" 1>&6


I wonder if this is causing problems for anyone, because it's *definitely*
wrong

Re: Odd, ptrace_getregs

[Andrew Cagney]

Mark Kettenis wrote:

> I was silently hoping nobody would notice :-(.  I corrected a typo in
> configure.in, but forgot to run autoconf before checking it in.  It's
> basically harmless since it is only the printing of the value that's
> broken.  I just hoped that someone would find the need to regenerate
> configure soon.  Feel free to check in a regenerated autoconf.

Have a look for the fateful phrase ``Fix typo.'' in the ChangeLogs :-) 
It should make you feel like you're not alone :-)

	Andrew
From ac131313@cygnus.com Mon Mar 13 23:46:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Michael Snyder <msnyder@cygnus.com>
Cc: dan@cgsoftware.com, Mark Kettenis <kettenis@wins.uva.nl>, gdb@sourceware.cygnus.com
Subject: Re: lin-thread cannot handle thread exit
Date: Mon, 13 Mar 2000 23:46:00 -0000
Message-id: <38CDEDC5.4107034@cygnus.com>
References: <200003031635.e23GZwi00372@delius.kettenis.local> <38C59074.2D7C@cygnus.com> <u2ihhvav.fsf@dan.resnet.rochester.edu> <38C7EDFB.7457@cygnus.com>
X-SW-Source: 2000-03/msg00229.html
Content-length: 1037

Michael Snyder wrote:
> 

> > All i ever debug on BeOS is multi-threaded apps.
> > Almost anything you do involves threads.
> > Open a window, you've started at least 2 threads.
> > File selection boxes fill in a seperate thread, etc.
> > So i constantly have threads coming and going, and doing things.
> > The hardest part of the whole port of gdb is telling gdb what
> > happened, and making gdb do the right thing.
> > On BeOS, we don't even have processes, just teams and threads.
> > Everything on BeOS works, except typing run and have it start (you
> > have to run and continue) :P.
> > I looked at thread_db over the weekend, in hopes of being able to redo
> > the port and get it into GDB (it's badly needing a rewrite anyway),
> > but it still looks like it has too many problems.
> 
> What problems are you referring to?
> Right now the only one I'm aware of is that it doesn't
> detect thread exit.

Michael,

Did you get any further with this?  Did the problem exist in the old
thread implementation for instance?

	Andrew
From akale@veritas.com Tue Mar 14 00:17:00 2000
From: "Amit S. Kale" <akale@veritas.com>
To: gdb@sourceware.cygnus.com
Subject: special symbol file address -1: debug lin-kern mods
Date: Tue, 14 Mar 2000 00:17:00 -0000
Message-id: <00031413504601.13017@fermat.vxindia.veritas.com>
X-SW-Source: 2000-03/msg00230.html
Content-length: 1220

Hi,

I have been trying to get gdb working at loading linux kernel modules via
'add-symbol-file'. Since it doesn't work properly with gdb, I tried to patch
gdb but in vein ( 'regression caused by elfread.c patch' thread ).

I had patched gdb 4.18 before I started using current gdb. The patch disabled
relocations if symbol file load address was -1.

e.g. add-symbol-file foo.reloc -1 
loads foo.reloc without relocating. Where foo.reloc is built from linux kernel
module foo using ld.

ld -o foo.reloc -Ttext< module text address> -Tdata<module data address>
-Tbss<module bss address> -R vmlinux -noinhibit-exec foo

How about adding this feature in gdb?
Thanks.
-- 
Amit Kale
Veritas Software ( http://www.veritas.com )


P.S. Above mentions patch for gdb-4.18 was as follows
diff -Naur gdb-4.18/gdb/symfile.c gdb/gdb/symfile.c
--- gdb-4.18/gdb/symfile.c	Thu Feb 11 05:54:38 1999
+++ gdb/gdb/symfile.c	Mon Dec 27 16:15:56 1999
@@ -525,7 +525,7 @@
      and assume that <addr> is where that got loaded.  Due to historical
      precedent, we warn if that doesn't happen to be a text segment.  */
 
-  if (mainline)
+  if (mainline || addr == -1)
     {
       addr = 0;		/* No offset from objfile addresses.  */
     }
From msnyder@cygnus.com Tue Mar 14 10:15:00 2000
From: Michael Snyder <msnyder@cygnus.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: dan@cgsoftware.com, Mark Kettenis <kettenis@wins.uva.nl>, gdb@sourceware.cygnus.com, drepper@cygnus.com
Subject: Re: lin-thread cannot handle thread exit
Date: Tue, 14 Mar 2000 10:15:00 -0000
Message-id: <38CE81B2.9CA@cygnus.com>
References: <200003031635.e23GZwi00372@delius.kettenis.local> <38C59074.2D7C@cygnus.com> <u2ihhvav.fsf@dan.resnet.rochester.edu> <38C7EDFB.7457@cygnus.com> <38CDEDC5.4107034@cygnus.com>
X-SW-Source: 2000-03/msg00231.html
Content-length: 1313

Andrew Cagney wrote:
> 
> Michael Snyder wrote:
> >
> 
> > > All i ever debug on BeOS is multi-threaded apps.
> > > Almost anything you do involves threads.
> > > Open a window, you've started at least 2 threads.
> > > File selection boxes fill in a seperate thread, etc.
> > > So i constantly have threads coming and going, and doing things.
> > > The hardest part of the whole port of gdb is telling gdb what
> > > happened, and making gdb do the right thing.
> > > On BeOS, we don't even have processes, just teams and threads.
> > > Everything on BeOS works, except typing run and have it start (you
> > > have to run and continue) :P.
> > > I looked at thread_db over the weekend, in hopes of being able to redo
> > > the port and get it into GDB (it's badly needing a rewrite anyway),
> > > but it still looks like it has too many problems.
> >
> > What problems are you referring to?
> > Right now the only one I'm aware of is that it doesn't
> > detect thread exit.
> 
> Michael,
> 
> Did you get any further with this?  Did the problem exist in the old
> thread implementation for instance?
> 
>         Andrew

As far as I can tell, yes it did.
This is something that the thread_db implementation was
designed to handle -- I just didn't get around to it.
I hope to be able to fit it in "real soon now".
From kingdon@redhat.com Tue Mar 14 11:30:00 2000
From: Jim Kingdon <kingdon@redhat.com>
To: gdb@sourceware.cygnus.com
Subject: Re: unloading shared objects
Date: Tue, 14 Mar 2000 11:30:00 -0000
Message-id: <bln3l1hed.fsf@rtl.cygnus.com>
References: <200003131759.SAA07581@reisser.regent.e-technik.tu-muenchen.de> <np4saabhsk.fsf@zwingli.cygnus.com>
X-SW-Source: 2000-03/msg00232.html
Content-length: 1875

> At present, GDB assumes that we know the shared object's load address
> when we read the symbols.  Perhaps this is a poor assumption, but it
> is pretty fundamental to the current symbol table structure.  I'm not
> going to fix that as part of this dlclose change.

Well, objfile_relocate was written to address this.  But I agree,
trying to fix this as part of the dlclose fix could be biting off more
than is warranted.

> - free_objfile calls CLEAR_SOLIB, which isn't what we want, I think.

Ouch.  That looks really bad.  I suspect the CLEAR_SOLIB call can and
should be moved up to symbol_file_command (note the call to
SOLIB_RESTART - currently vestigial at least on Linux - which relates
to the issue of whether to nuke all the shared library symbols on
every run of the program).

> - Selecting a core file and attaching to a process both add the shared
> libraries' sections to the target_ops structure.  When we unload a
> shared library, we close the BFD those sections refer to.  We
> need to remove those sections from the target_ops structure.

You noticed that one too, eh? ;-).

> - Should solib.c be maintaining its own list of shared objects at all,
>   or should it always retrieve the full link map from the inferior,
>   and use the objfile list itself as our record of what we know about?

Haven't looked at the code long enough to have a really good feel for
this, but I think you are probably right.  That your changes to nuke
find_solib separate out the inferior access code enough to make the
above practical.

Anyway, thanks for writing this code and let me know if there is
anything else I can do (at the moment, various ideas and encouragement
seem like a better way for me to help than writing code - not only was
my solib.c code somewhat buggy/unpopular, but I didn't really enjoy
writing it either :-)).
From jtc@redback.com Tue Mar 14 14:10:00 2000
From: jtc@redback.com (J.T. Conklin)
To: Andrew Cagney <ac131313@cygnus.com>
Cc: GDB <gdb@sourceware.cygnus.com>
Subject: Re: breakpoint insert API (was: A patch for ia32 hardware watchpoint.)
Date: Tue, 14 Mar 2000 14:10:00 -0000
Message-id: <5m8zzl6w5r.fsf@jtc.redbacknetworks.com>
References: <200003080845.AAA18410@alabama.wrs.com> <5mitywc5ac.fsf@jtc.redbacknetworks.com> <38C834AD.3379D1F2@cygnus.com>
X-SW-Source: 2000-03/msg00233.html
Content-length: 1629

>>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
Andrew> One aspect of this gives me cold feet and sweety palms.
Andrew> You're giving the target code access to the entire bp struct.
Andrew> While I don't have any problems with handing the code a
Andrew> breakpoint handle, I have strong reservations towards any
Andrew> moves that give the target unfettered access to the entire
Andrew> ``struct breakpoint''.  We'll be spending the next 10 years
Andrew> trying to get control back again :-)

I appreciate this argument, and agree that the target interface should
be as robust as possible.  After reading your message, I thought about
hiding the fact that the argument is a struct breakpoint pointer and
providing macros to access "public" fields, but any subversion we do
can be undone by a clever programmer.  I'm still working on something 
that is simple, elegant, and efficent.

However, I think it's a bit of a stretch to say such changes in and of
themselves will lead to GDB being out of control.  IMHO, this can only
happen if the GDB maintainers fail to do their jobs and integrate code
that disrupts GDB's architectural integrity.  I'll stipulate that
we've done a rather poor job of this in the past, but I'm hopeful that
attitudes have changed.

Andrew> I'd prefer to see something that tightens rather than loosens
Andrew> access to ``struct breakpoint''.  Perhaphs something along the
Andrew> lines of multi-arch where the target is notified of breakpoint
Andrew> create, insert, remove, delete operations.

I don't quite follow.  Care to elaborate?

        --jtc

-- 
J.T. Conklin
RedBack Networks
From jtc@redback.com Tue Mar 14 14:47:00 2000
From: jtc@redback.com (J.T. Conklin)
To: Stephane.Bihan@arccores.com
Cc: gdb@sourceware.cygnus.com (GDB)
Subject: Re: breakpoint insert API (was: A patch for ia32 hardware watchpoint.)
Date: Tue, 14 Mar 2000 14:47:00 -0000
Message-id: <5m4sa96uf1.fsf@jtc.redbacknetworks.com>
References: <OFAC328FD6.59EE621C-ON802568A1.0034EAE9@risccores.com>
X-SW-Source: 2000-03/msg00234.html
Content-length: 2418

>>>>> "Stephane" == Stephane Bihan <Stephane.Bihan@arccores.com> writes:

jtc> One issue that I'm not sure how to address is that there are several
jtc> places breakpoints are inserted where a breakpoint has not been
jtc> constructed.  Most of these occur in tdep code which implements single
jtc> step with breakpoints on processors without a trace mode.

Todd> Aiee! Such code is evil and must be destroyed.

Stephane> It seems to me that this single_step function is actually
Stephane> not in use.  I don't know about WindRiver, but here we have
Stephane> two targets: an ISS and a remote target that use the generic
Stephane> breakpoint functions before stepping.  I don't mind to
Stephane> remove this code.

I assume you are refering to the ARC port?

I see three GDB ports that do single step in software: arc, rs6000,
and sparc.  The arc and sparc ports, insert breakpoints with target-
_insert_breakpoint().  The rs6000 port by reading and writing memory
directly.  Of the two methods, I prefer target_insert_breakpoint().

However, if the breakpoint insert/remove API was changed to require a
struct breakpoint pointer, we couldn't call target_insert_breakpoint()
in the foo_single_step() functions without creating a real breakpoint
object to pass through that first pointer.   

Another reason we might want a real breakpoint for this is that when
my memory region attribute code is complete we'll be able to say that
breakpoints in a region should be done with hardware breakpoints.  A
user can debug his/her own code in read-only memory by using hbreak,
but there is no way to tell GDB to use hardware breakpoints for step,
next, continue, finish, until, etc.  One thing that surprised me was
that the single step code used multiple breakpoints.  That would put a
lot of pressure on hardware breakpoint registers.  I suspect that GDB
has all the information in order to insert a single breakpoint (by
evaluating which way a conditional branch will go, etc.).


Since you say you can remove the single step code, I assume that the
ISS target and remote protocol agents can perform the single step by
themselves?  If so, it would be advantageous to disable GDB's single
step support.  GDB would then issue a single "step" command instead of
"insert breakpoint(s)", "continue", and "remove breakpoint(s)".  The
latency of a step should be greatly improved.

        --jtc

-- 
J.T. Conklin
RedBack Networks
From jtc@redback.com Tue Mar 14 14:56:00 2000
From: jtc@redback.com (J.T. Conklin)
To: Todd Whitesel <toddpw@windriver.com>
Cc: gdb@sourceware.cygnus.com (GDB)
Subject: Re: breakpoint insert API (was: A patch for ia32 hardware watchpoint.)
Date: Tue, 14 Mar 2000 14:56:00 -0000
Message-id: <5mzos15ffa.fsf@jtc.redbacknetworks.com>
References: <200003100133.RAA00070@alabama.wrs.com>
X-SW-Source: 2000-03/msg00235.html
Content-length: 1362

>>>>> "Todd" == Todd Whitesel <toddpw@windriver.com> writes:
jtc> One issue that I'm not sure how to address is that there are several
jtc> places breakpoints are inserted where a breakpoint has not been
jtc> constructed.  Most of these occur in tdep code which implements single
jtc> step with breakpoints on processors without a trace mode.

Todd> Aiee! Such code is evil and must be destroyed.

I don't think it's that bad.  

Todd> One important value of the full breakpoint machinery is that it
Todd> can help avoid the same location being patched twice. Any time
Todd> we patch the same instruction twice, we must un-patch it in
Todd> exactly reverse order or else we leave a breakpoint instruction
Todd> sitting in the code -- Not Good.

Todd> So I would have to argue that the singlestep logic must either
Todd> happen at a really low level (this guarantees it will patch last
Todd> and un-patch first) or must go through the real breakpoint logic
Todd> which can do duplicate detection.

The SOFTWARE_SINGLE_STEP() macro is called at a low enough level that
it inserts and remove trap instructions without effecting GDB's high-
level breakpoints.  So I think we're OK.  As a result, I wouldn't be
suprised if steping into a breakpoint didn't behave the same as on a
machine with hardware single-step.  

        --jtc

-- 
J.T. Conklin
RedBack Networks
From jtc@redback.com Tue Mar 14 15:15:00 2000
From: jtc@redback.com (J.T. Conklin)
To: gdb@sourceware.cygnus.com (GDB)
Subject: Re: breakpoint insert API (was: A patch for ia32 hardware watchpoint.)
Date: Tue, 14 Mar 2000 15:15:00 -0000
Message-id: <5mvh2p5elj.fsf@jtc.redbacknetworks.com>
References: <200003100128.RAA00013@alabama.wrs.com>
X-SW-Source: 2000-03/msg00236.html
Content-length: 1291

>>>>> "Todd" == Todd Whitesel <toddpw@windriver.com> writes:
Andrew> I'd prefer to see something that tightens rather than loosens
Andrew> access to ``struct breakpoint''.  Perhaphs something along the
Andrew> lines of multi-arch where the target is notified of breakpoint
Andrew> create, insert, remove, delete operations.

Todd> Basically what I need is the moral equivalent of a "user" field
Todd> tacked onto every breakpoint struct.
Todd>
Todd> Based on my existing code, the contents of this field would be:
Todd> 	UINT32	breakpointID; /* WTX-supplied handle for this breakpoint */
Todd> 	bool	is_foreign;   /* true if breakpoint was set by someone else */
Todd> 	bool	is_global;    /* true if breakpoint active for all tasks */

The reason I was passing the breakpoint pointer (with the intention of
adding a "void *private_data" field), is that I don't want to preclude
any target implementation.  A 32 bit integer ID is probably the most
common breakpoint handle, but you never can tell...

I don't think your is_foreign flag is suitable for the target specific
data, because it changes the behavior of generic breakpoint code.  You
didn't describe is_global, so I'm not sure about it.  How is it
different from (bp->thread == -1)?

        --jtc

-- 
J.T. Conklin
RedBack Networks
From toddpw@windriver.com Tue Mar 14 15:31:00 2000
From: Todd Whitesel <toddpw@windriver.com>
To: jtc@redback.com
Cc: gdb@sourceware.cygnus.com (GDB Developers)
Subject: Re: breakpoint insert API (was: A patch for ia32 hardware watchpoint.)
Date: Tue, 14 Mar 2000 15:31:00 -0000
Message-id: <200003142331.PAA18553@alabama.wrs.com>
References: <5mvh2p5elj.fsf@jtc.redbacknetworks.com>
X-SW-Source: 2000-03/msg00237.html
Content-length: 1137

> The reason I was passing the breakpoint pointer (with the intention of
> adding a "void *private_data" field), is that I don't want to preclude
> any target implementation.  A 32 bit integer ID is probably the most
> common breakpoint handle, but you never can tell...

I didn't pretend that this was general enough for everyone, I only said
this was what I used. In my case the UINT32 is dictated by the WTX layer
that assigns the ID's.

> I don't think your is_foreign flag is suitable for the target specific
> data, because it changes the behavior of generic breakpoint code.

Hmm, actually yeah that's right. It probably should be generic.

> You didn't describe is_global, so I'm not sure about it.  How is it
> different from (bp->thread == -1)?

It probably isn't, and is more an artifact of my implementation.

The foreign/global stuff was added together, and happened late enough
in a development cycle that I needed to keep it isolated and easy to
compile back out if we had to cancel it. I had two distinct #ifdef's
so I could pinpoint all the changes; I've never taken those out.

-- 
Todd Whitesel
toddpw @ windriver.com
From jtc@redback.com Tue Mar 14 15:36:00 2000
From: jtc@redback.com (J.T. Conklin)
To: gdb@sourceware.cygnus.com
Subject: memory region attribute CLI
Date: Tue, 14 Mar 2000 15:36:00 -0000
Message-id: <5mr9dd5dlt.fsf@jtc.redbacknetworks.com>
X-SW-Source: 2000-03/msg00238.html
Content-length: 1326

I've been told to work on memory region attributes full time, so I
expect to make significant progress in the next few days.  

* create memory region:

        mem <start> <end> attribute [attribute ...]

  example:
        (gdb) mem 0x00008000 0x0000FFFF ro 8
        (gdb) mem 0x00007FF0 0x00007FFF rw
        (gdb) mem 0x00007FE0 0x00007FEF wo 16
        (gdb) mem 0x00007FD0 0x00007FDF ro
        

  I've followed the behavior of "display" and do not output a message
  indicating the number of the memory region that has been created.
  But as I write this message, it seems that it probably should.  I
  think an argument could be made that the same should be done for
  displays...

* enable/disable memory region:

        enable mem <region-id> [<region-id> ...]
        disable mem <region-id> [<region-id> ...]

  example:
        (gdb) disable mem 2

* delete memory regions:

        delete mem <region-id> [<region-id> ...]

  example:
        (gdb) delete mem 3

* show memory regions:

        info mem

  example:
        (gdb) info mem
        Num     Enb     Address                 Attr
        1:      y       0x00008000-0x0000FFFF   ro, 8
        2:      n       0x00007FF0-0x00007FFF   rw
        4:      y       0x00007FD0-0x00007FDF   ro

Thoughts?

        --jtc

-- 
J.T. Conklin
RedBack Networks
From ac131313@cygnus.com Tue Mar 14 16:39:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Michael Snyder <msnyder@cygnus.com>
Cc: dan@cgsoftware.com, Mark Kettenis <kettenis@wins.uva.nl>, gdb@sourceware.cygnus.com, drepper@cygnus.com
Subject: Re: lin-thread cannot handle thread exit
Date: Tue, 14 Mar 2000 16:39:00 -0000
Message-id: <38CEDB3E.DA17FA9A@cygnus.com>
References: <200003031635.e23GZwi00372@delius.kettenis.local> <38C59074.2D7C@cygnus.com> <u2ihhvav.fsf@dan.resnet.rochester.edu> <38C7EDFB.7457@cygnus.com> <38CDEDC5.4107034@cygnus.com> <38CE81B2.9CA@cygnus.com>
X-SW-Source: 2000-03/msg00239.html
Content-length: 427

Michael Snyder wrote:

> As far as I can tell, yes it did.
> This is something that the thread_db implementation was
> designed to handle -- I just didn't get around to it.
> I hope to be able to fit it in "real soon now".

So this effectivly means that this particular thread problem is a ``nice
to have'' rather than a ``must have'' for 5.0.

Something that can be better easier fixed in the 5.1 timeframe.

	enjoy,
		Andrew
From msnyder@cygnus.com Tue Mar 14 17:01:00 2000
From: Michael Snyder <msnyder@cygnus.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: dan@cgsoftware.com, Mark Kettenis <kettenis@wins.uva.nl>, gdb@sourceware.cygnus.com, drepper@cygnus.com
Subject: Re: lin-thread cannot handle thread exit
Date: Tue, 14 Mar 2000 17:01:00 -0000
Message-id: <38CEE0DD.11A@cygnus.com>
References: <200003031635.e23GZwi00372@delius.kettenis.local> <38C59074.2D7C@cygnus.com> <u2ihhvav.fsf@dan.resnet.rochester.edu> <38C7EDFB.7457@cygnus.com> <38CDEDC5.4107034@cygnus.com> <38CE81B2.9CA@cygnus.com> <38CEDB3E.DA17FA9A@cygnus.com>
X-SW-Source: 2000-03/msg00240.html
Content-length: 472

Andrew Cagney wrote:
> 
> Michael Snyder wrote:
> 
> > As far as I can tell, yes it did.
> > This is something that the thread_db implementation was
> > designed to handle -- I just didn't get around to it.
> > I hope to be able to fit it in "real soon now".
> 
> So this effectivly means that this particular thread problem is a ``nice
> to have'' rather than a ``must have'' for 5.0.
> 
> Something that can be better easier fixed in the 5.1 timeframe.

I would say so.
From huayan_us@yahoo.com Tue Mar 14 18:43:00 2000
From: hua yan <huayan_us@yahoo.com>
To: gdb@sourceware.cygnus.com
Cc: insight@sourceware.cygnus.com
Subject: how to include iwidgets3.0
Date: Tue, 14 Mar 2000 18:43:00 -0000
Message-id: <20000315024243.24818.qmail@web4002.mail.yahoo.com>
X-SW-Source: 2000-03/msg00241.html
Content-length: 1981

Dear Consultant:
  I've written an tcl program using Iwidgets 3.0 's
class ---- iwidgets::Fileselectionbox. If run it in
Itcl environment that is if I have insalled the Itcl
(my O.S is  Windows NT 4.0) ,there is no problem.But
if I write an C program to startup the Tcl file, some
problems will raised.
Problem 1:
 In my C file there have include the following
sentences:
int Tcl_AppInit(Tcl_Interp *interp) {

     
      if (Tcl_Init(interp) != TCL_OK)    {
          return TCL_ERROR;
        }


      if (Tk_Init(interp) != TCL_OK)     {
          return TCL_ERROR;
        }

      if (Itcl_Init(interp) != TCL_OK)   {
           return TCL_ERROR;
         }

      if (Itk_Init(interp) != TCL_OK)    {
           return TCL_ERROR;
         }


      return TCL_OK;
} 

In my main.tcl file, there have include the following
sentences:
package require Tcl 8.0
package require Tk 8.0
package require Itcl 3.0
package require Itk 3.0
package require Iwidgets 3.0


if {![find_iwidgets_library]} {
  tk_messageBox -title Error -message "Could not find
the Iwidgets libraries.
Got nameofexec: [info nameofexecutable]
Error(s) were: \n$errMsg" \
      -icon error -type ok
  exit
}

but the error messege "Error: error while autoloading
"iwidgets:Fileselectionbox": invalid command name
"class"" will appear.

Problem 2:
In my C file, if call the function
"freeconsole()",then
in my Tcl, all places including {open "|..."} being
executed, can not launch the program,error message
"Error: couldn't duplicate input handle:bad file
number" will appear. if not call the
"freeconsole",then behind my main interface there is
always an blank screen, but can launch the program.

problem 3:
if startup the program from C file, then my main menu
will display some curious characters if the original
character is chinese.

best wishes
huayan
2000-3-15


__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com
From fedor@doc.com Tue Mar 14 19:54:00 2000
From: Adam Fedor <fedor@doc.com>
To: gdb@sourceware.cygnus.com
Subject: Objective-C patches?
Date: Tue, 14 Mar 2000 19:54:00 -0000
Message-id: <38CF0958.DCEDD532@doc.com>
X-SW-Source: 2000-03/msg00242.html
Content-length: 473

I read a rather cryptic remark on the list a while back that indicated
that the Objective-C patches from Apple/NeXT would be integrated into
GDB soon (maybe by 5.1?). Is this true or are the patches still
languishing? Is a volunteer necessary for getting this going?

-- 
Adam Fedor, Digital Optics            | Fudd's law of opposition: Push
fedor@doc.com ( http://www.doc.com )    | something hard enough, and it
will
fedor@gnu.org ( http://www.gnustep.org )| fall over.
From Stephane.Bihan@arccores.com Wed Mar 15 04:21:00 2000
From: Stephane.Bihan@arccores.com
To: jtc@redback.com
Cc: Yuri Karlsbrun <yuri@cmln.com>, gdb@sourceware.cygnus.com
Subject: Re: breakpoint insert API (was: A patch for ia32 hardware watchpoint.)
Date: Wed, 15 Mar 2000 04:21:00 -0000
Message-id: <OFEE916CF4.EFD71D61-ON802568A3.003AFF62@risccores.com>
X-SW-Source: 2000-03/msg00243.html
Content-length: 3416

> >>>>> "Stephane" == Stephane Bihan <Stephane.Bihan@arccores.com> writes:
>
> jtc> One issue that I'm not sure how to address is that there are several
> jtc> places breakpoints are inserted where a breakpoint has not been
> jtc> constructed.  Most of these occur in tdep code which implements single
> jtc> step with breakpoints on processors without a trace mode.
>
> Todd> Aiee! Such code is evil and must be destroyed.
>
> Stephane> It seems to me that this single_step function is actually
> Stephane> not in use.  I don't know about WindRiver, but here we have
> Stephane> two targets: an ISS and a remote target that use the generic
> Stephane> breakpoint functions before stepping.  I don't mind to
> Stephane> remove this code.
>
> I assume you are refering to the ARC port?

yes. But I was actually wrong in my last email, the single step function in
arc-tdep is
used, I was thinking to another function, sorry.
What do you mean by breakpoint without a trace mode?

>
> I see three GDB ports that do single step in software: arc, rs6000,
> and sparc.  The arc and sparc ports, insert breakpoints with target-
> _insert_breakpoint().  The rs6000 port by reading and writing memory
> directly.  Of the two methods, I prefer target_insert_breakpoint().
>
> However, if the breakpoint insert/remove API was changed to require a
> struct breakpoint pointer, we couldn't call target_insert_breakpoint()
> in the foo_single_step() functions without creating a real breakpoint
> object to pass through that first pointer.

I don't know what are the foo_single_step functions.

I also use the breakpoint structure as an extern variable. I needed
it to implement the set_hw_breakpoint routine for the remote protocol.
I think it's not the nicer way to do but ....

> Another reason we might want a real breakpoint for this is that when
> my memory region attribute code is complete we'll be able to say that
> breakpoints in a region should be done with hardware breakpoints.
> A user can debug his/her own code in read-only memory by using hbreak,
> but there is no way to tell GDB to use hardware breakpoints for step,
> next, continue, finish, until, etc.  One thing that surprised me was
> that the single step code used multiple breakpoints.  That would put a
> lot of pressure on hardware breakpoint registers.  I suspect that GDB
> has all the information in order to insert a single breakpoint (by
> evaluating which way a conditional branch will go, etc.).
>

What would be a "real breakpoint"? a pointer to the breakpoint structure?

>
> Since you say you can remove the single step code, I assume that the
> ISS target and remote protocol agents can perform the single step by
> themselves?  If so, it would be advantageous to disable GDB's single
> step support.  GDB would then issue a single "step" command instead of
> "insert breakpoint(s)", "continue", and "remove breakpoint(s)".  The
> latency of a step should be greatly improved.

I will implement this for the remote target only since the hardware supports
single-stepping.
I'm not sure if this feasible in the ISS - Yuri?

If not feasible I won't disable the GDB's single step support (thus enabling a
call to single_step())
but I will implement a single_step call to gdbstub in remote_resume().

Stephane.

----------------------------------------------------------------
Stephane Bihan
ARC Cores Ltd            http://www.arccores.com

Re: Odd, ptrace_getregs

[Mark Kettenis]

   Date: Mon, 13 Mar 2000 08:55:25 -0800 (PST)
   From: Daniel Berlin <dan@cgsoftware.com>

   I was just generating some diffs, and noticed this:
   RCS file: /cvs/src/src/gdb/configure,v
   retrieving revision 1.11
   diff -r1.11 configure
   3737c3737
   < echo "$ac_t""$gdb_cv_have_ptrace_geregs" 1>&6
   ---
   > echo "$ac_t""$gdb_cv_have_ptrace_getregs" 1>&6


   I wonder if this is causing problems for anyone, because it's *definitely*
   wrong

I was silently hoping nobody would notice :-(.  I corrected a typo in
configure.in, but forgot to run autoconf before checking it in.  It's
basically harmless since it is only the printing of the value that's
broken.  I just hoped that someone would find the need to regenerate
configure soon.  Feel free to check in a regenerated autoconf.

Mark