Re: gdb and jeeni

Re: gdb and jeeni

[Fernando Nasser]

Wrong list.  This should have been posted to insight@sourceware.cygnus.com as it is
a GUI only problem.

Anyway, I can't reproduce this problem here.  Something is really bad with your Tcl
as it is generating a combobox event (which is the only case the change_baud is called).

I don't know what is causing this spurious call, but I can add a guard against this.
Please try the attached patch and let me know if it solved your problem.

Thanks.

Fernando

P.S.: Please drop the gdb list when replying.  Thanks.



Shaun Jackman wrote:
> 
> I'm running Insight 5.0 --target=arm-elf --host=i686-pc-linux-gnu and a jeeni
> (ARM Angel/Ethernet). When I click "Target Settings" I get the error 'No symbol
> "ETH" in current context.'
> The stack trace is:
> No symbol "ETH" in current context.
> 
>     while executing
> "gdb_cmd "set remotebaud $baud""
>     (object "::.targetselection0.targetselection" method "::TargetSelection::change_baud" body line 4)
>     invoked from within
> "::.targetselection0.targetselection change_baud .targetselection0.targetselection.f.lab.lf.childsite.cb ETH"
>     (in namespace inscope "::TargetSelection" script line 1)
>     invoked from within
> "namespace inscope ::TargetSelection {::.targetselection0.targetselection change_baud} .targetselection0.targetselection.f.lab.lf.childsite.cb ETH"
>     ("after" script)errorCode is NONE
> 
> Cheers,
> Shaun



===================================================================
RCS file: /cvs/src/src/gdb/gdbtk/library/targetselection.itb,v
retrieving revision 1.1.1.1
diff -c -p -r1.1.1.1 targetselection.itb
*** targetselection.itb 2000/02/07 00:19:42     1.1.1.1
--- targetselection.itb 2000/08/03 20:49:38
*************** body TargetSelection::change_target {w {
*** 769,775 ****
  # ------------------------------------------------------------------
  body TargetSelection::change_baud {w {baud ""}} {
    if {$baud != ""} {
!     if {[string compare $baud "TCP"] != 0} {
        gdb_cmd "set remotebaud $baud"
        if {[catch {gdb_cmd "show remotebaud"} res]} {
        set newbaud 0
--- 769,776 ----
  # ------------------------------------------------------------------
  body TargetSelection::change_baud {w {baud ""}} {
    if {$baud != ""} {
!     if {([string compare $baud "TCP"] != 0)
!         && ([string compare $baud "ETX"] != 0)} {
        gdb_cmd "set remotebaud $baud"
        if {[catch {gdb_cmd "show remotebaud"} res]} {
        set newbaud 0



-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@cygnus.com
2323 Yonge Street, Suite #300           Tel:  416-482-2661 ext. 311
Toronto, Ontario   M4P 2C9              Fax:  416-482-6299
From ngupta@zumanetworks.com Thu Aug 03 15:57:00 2000
From: "niraj gupta" <ngupta@zumanetworks.com>
To: <gdb@sources.redhat.com>
Subject: build isuues with m68k-linux target on x86 host
Date: Thu, 03 Aug 2000 15:57:00 -0000
Message-id: <000f01bffd9d$7f3d9ba0$d301a8c0@internal.nbase.com>
X-SW-Source: 2000-08/msg00030.html
Content-length: 332

i get unresolved on  in_sigtramp()

changing in tm-linux.h

#define IN_SIGTRAMP(pc,name) in_sigtramp (pc)
extern int in_sigtramp (CORE_ADDR pc);

to

extern int delta68_in_sigtramp (CORE_ADDR pc, char *name);
#define IN_SIGTRAMP(pc,name) delta68_in_sigtramp (pc, name)


seems to work, don't know if this is the right change

niraj
From kevinb@cygnus.com Thu Aug 03 16:23:00 2000
From: Kevin Buettner <kevinb@cygnus.com>
To: "niraj gupta" <ngupta@zumanetworks.com>, <gdb@sources.redhat.com>
Subject: Re: build isuues with m68k-linux target on x86 host
Date: Thu, 03 Aug 2000 16:23:00 -0000
Message-id: <1000803232327.ZM3079@ocotillo.lan>
References: <000f01bffd9d$7f3d9ba0$d301a8c0@internal.nbase.com> <ngupta@zumanetworks.com>
X-SW-Source: 2000-08/msg00031.html
Content-length: 1031

On Aug 3,  3:52pm, niraj gupta wrote:

> i get unresolved on  in_sigtramp()
> 
> changing in tm-linux.h
> 
> #define IN_SIGTRAMP(pc,name) in_sigtramp (pc)
> extern int in_sigtramp (CORE_ADDR pc);
> 
> to
> 
> extern int delta68_in_sigtramp (CORE_ADDR pc, char *name);
> #define IN_SIGTRAMP(pc,name) delta68_in_sigtramp (pc, name)
> 
> 
> seems to work, don't know if this is the right change

I doubt it.  My recollection is that the Delta 68 is a very
old m68k machine made by Motorola.  (When I used them, they
ran SVR3.)

It is very unlikely that the mechanism for detecting that you're
in the signal trampoline code is the same for both linux and the old
delta68s.

It looks to me like you need to move in_sigtramp() from m68klinux-nat.c
to m68k-tdep.c.  (Also, you'll want to rename it to something like
m68klinux_in_sigtramp()).

After looking at in_sigtramp() in m68klinux-nat.c, I see absolutely
no reason for it being there.  It looks to me like it should build
just fine if moved (and renamed) to the tdep.c file.

Kevin
From gerwynd@tommoll.freeserve.co.uk Thu Aug 03 17:06:00 2000
From: "Gerwyn Davies" <gerwynd@tommoll.freeserve.co.uk>
To: "GDB" <gdb@sourceware.cygnus.com>
Subject: GDB error messages
Date: Thu, 03 Aug 2000 17:06:00 -0000
Message-id: <002301bffda8$4e0d70e0$ec08883e@gtd-s-machine>
X-SW-Source: 2000-08/msg00032.html
Content-length: 243

Hi,

A could anyone tell me what the cause is of the following GDB error
messages:-

"Don't know how to run" in response to a 'run' command.
and
"You can't do that when your target is `exec' " in response to a load
command.

Thanks

Gerwyn

Re: gdb and jeeni

[Fernando Nasser]

Did you try it?

Fernando


Fernando Nasser wrote:
> 
> Wrong list.  This should have been posted to insight@sourceware.cygnus.com as it is
> a GUI only problem.
> 
> Anyway, I can't reproduce this problem here.  Something is really bad with your Tcl
> as it is generating a combobox event (which is the only case the change_baud is called).
> 
> I don't know what is causing this spurious call, but I can add a guard against this.
> Please try the attached patch and let me know if it solved your problem.
> 
> Thanks.
> 
> Fernando
> 
> P.S.: Please drop the gdb list when replying.  Thanks.
> 
> Shaun Jackman wrote:
> >
> > I'm running Insight 5.0 --target=arm-elf --host=i686-pc-linux-gnu and a jeeni
> > (ARM Angel/Ethernet). When I click "Target Settings" I get the error 'No symbol
> > "ETH" in current context.'
> > The stack trace is:
> > No symbol "ETH" in current context.
> >
> >     while executing
> > "gdb_cmd "set remotebaud $baud""
> >     (object "::.targetselection0.targetselection" method "::TargetSelection::change_baud" body line 4)
> >     invoked from within
> > "::.targetselection0.targetselection change_baud .targetselection0.targetselection.f.lab.lf.childsite.cb ETH"
> >     (in namespace inscope "::TargetSelection" script line 1)
> >     invoked from within
> > "namespace inscope ::TargetSelection {::.targetselection0.targetselection change_baud} .targetselection0.targetselection.f.lab.lf.childsite.cb ETH"
> >     ("after" script)errorCode is NONE
> >
> > Cheers,
> > Shaun
> 
> ===================================================================
> RCS file: /cvs/src/src/gdb/gdbtk/library/targetselection.itb,v
> retrieving revision 1.1.1.1
> diff -c -p -r1.1.1.1 targetselection.itb
> *** targetselection.itb 2000/02/07 00:19:42     1.1.1.1
> --- targetselection.itb 2000/08/03 20:49:38
> *************** body TargetSelection::change_target {w {
> *** 769,775 ****
>   # ------------------------------------------------------------------
>   body TargetSelection::change_baud {w {baud ""}} {
>     if {$baud != ""} {
> !     if {[string compare $baud "TCP"] != 0} {
>         gdb_cmd "set remotebaud $baud"
>         if {[catch {gdb_cmd "show remotebaud"} res]} {
>         set newbaud 0
> --- 769,776 ----
>   # ------------------------------------------------------------------
>   body TargetSelection::change_baud {w {baud ""}} {
>     if {$baud != ""} {
> !     if {([string compare $baud "TCP"] != 0)
> !         && ([string compare $baud "ETX"] != 0)} {
>         gdb_cmd "set remotebaud $baud"
>         if {[catch {gdb_cmd "show remotebaud"} res]} {
>         set newbaud 0
> 
> --
> Fernando Nasser
> Red Hat Canada Ltd.                     E-Mail:  fnasser@cygnus.com
> 2323 Yonge Street, Suite #300           Tel:  416-482-2661 ext. 311
> Toronto, Ontario   M4P 2C9              Fax:  416-482-6299

-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@cygnus.com
2323 Yonge Street, Suite #300           Tel:  416-482-2661 ext. 311
Toronto, Ontario   M4P 2C9              Fax:  416-482-6299
From jingham@apple.com Tue Aug 08 16:21:00 2000
From: Jim Ingham <jingham@apple.com>
To: <gdb@sources.redhat.com>
Subject: Changing the "enclosing_type" of a value structure
Date: Tue, 08 Aug 2000 16:21:00 -0000
Message-id: <B5B5E410.3CCA%jingham@apple.com>
X-SW-Source: 2000-08/msg00044.html
Content-length: 2587

Hi, all...

I found a number of places in the gdb sources where we are changing the
enclosing_type field of a value structure.  For instance, in
valops.c:3490ff,  the following is done:

   /* If we have the full object, but for some reason the enclosing
      type is wrong, set it *//* pai: FIXME -- sounds iffy */
   if (full)
     {
       VALUE_ENCLOSING_TYPE (argp) = real_type;
       return argp;
     }

NB: it is NOT a good idea to blythely change the enclosing type of a
value, since allocate_value uses the length of the enclosing type to
figure out the size of the data area to allocate at the end of the
"value structure".  So if the new enclosing_type is bigger than the one
you passed to allocate_value, and you ever go to read in the data, you
will stomp whatever happens to be after this value structure in memory,
causing all sorts of badness later on...  This bit of code was causing a
crash for just this reason when I was viewing member objects of a C++
class.

There are other cases like this (valops.c:791ff):

  /* Get target memory address */
  arg2 = value_from_pointer (lookup_pointer_type (VALUE_TYPE (arg1)),
                 (VALUE_ADDRESS (arg1)
                  + VALUE_OFFSET (arg1)
                  + VALUE_EMBEDDED_OFFSET (arg1)));

  /* This may be a pointer to a base subobject; so remember the
     full derived object's type ... */
  VALUE_ENCLOSING_TYPE (arg2) = lookup_pointer_type(VALUE_ENCLOSING_TYPE
(arg1));

Which happens to work because these are both pointers, and so have the same
size...

My software fascist side says you should NEVER be allowed to change the
enclosing_type of a value without at least putting in an assert making
sure that the new enclosing_type's length is <= that of the old
enclosing type.  After all, making an error here may cause memory
corruption in the application, which is generally pretty unpleasant to
track down.

It might even be good to introduce a function like:

value_ptr
value_change_enclosing_type (value_ptr val, type *new_type)
{
  if (TYPE_LENGTH (new_type) <= TYPE_LENGTH (VALUE_ENCLOSING_TYPE (val)))
    {
      VALUE_ENCLOSING_TYPE(val) = new_type;
      return val;
    }
  else
    {
       return (value_ptr) xrealloc (val, sizeof (struct type)
                                    + TYPE_LENGTH (new_type));
    }
}

and use that everywhere that we were just reassigning before.

If this makes sense to people (and/or I am not missing something
obvious), then I will whip up a patch and submit it.

Jim
-- 
Jim Ingham                                 jingham@apple.com
Apple Computer