auto-solib-add for "attach" as well as "run"

auto-solib-add for "attach" as well as "run"

[Michael Elizabeth Chastain]

I have an enhancement request where a gdb user wants the
"auto-solib-add" flag to work with the "attach" command as well
as the "run" command.

Superficially, this looks like an entirely reasonable thing to do.
"run" and "attach" are different in how they handle processes,
but ought to work the same for the whole symbol-handling side of
the debugger.

Can anyone point out any gotchas or drawbacks if I just go ahead
and make "attach" honor the "auto-solib-add" flag?

Michael Chastain
chastain@redhat.com
Cygnus Solutions, a Red Hat Company
From cogen@ll.mit.edu Thu May 04 14:15:00 2000
From: David Cogen <cogen@ll.mit.edu>
To: dan@cgsoftware.com
Cc: kettenis@wins.uva.nl, gdb@sourceware.cygnus.com, cogen@poblano
Subject: Re: gdb seg violation during print command
Date: Thu, 04 May 2000 14:15:00 -0000
Message-id: <200005042111.RAA24006@ll.mit.edu>
References: <Pine.LNX.4.10.10005041243050.28288-100000@propylaea.anduin.com>
X-SW-Source: 2000-05/msg00024.html
Content-length: 1062

> Try adding a line or three to main that do nothing.

Like this?

#include <iostream>

int tteesstt11 (int)
{
  cerr << "\n";
  return 4;
}

int main ()
{
  cout << "1\n";
  cout << "1\n";
  cout << "1\n";
  cout << "1\n";
  cout << "1\n";
  cout << "1\n";
  cout << "1\n";
  cout << "1\n";
  cout << "1\n";
  cout << "1\n";
  cout << "1\n";
  cout << "1\n";
  cout << "1\n";
  cout << "1\n";
  cout << "1\n";
  cout << "1\n";
  cout << "1\n";
  cout << "1\n";
  cout << "1\n";
  cout << "1\n";
  cout << "1\n";
  cout << "1\n";
  cout << "1\n";
  cout << "1\n";
  cout << "1\n";
  cout << "1\n";
  cout << "1\n";
  cout << "1\n";
  cout << "1\n";
  cout << "1\n";
  cout << "1\n";
  cout << "1\n";
  cout << "1\n";
  cout << "1\n";
  cout << "1\n";
  cout << "1\n";
  cout << "1\n";
  cout << "1\n";
  cout << "1\n";
  cout << "1\n";
  cout << "1\n";
  cout << "1\n";
  cout << "1\n";
  cout << "1\n";
  cout << "1\n";
  cout << "1\n";
}


I set my break on the first cout in main. When I print tteesstt11(1) I still
get the debugger seg violation.

-- DavidC
From dan@cgsoftware.com Thu May 04 14:20:00 2000
From: Daniel Berlin <dan@cgsoftware.com>
To: David Cogen <cogen@ll.mit.edu>
Cc: kettenis@wins.uva.nl, gdb@sourceware.cygnus.com, cogen@poblano
Subject: Re: gdb seg violation during print command
Date: Thu, 04 May 2000 14:20:00 -0000
Message-id: <Pine.LNX.4.10.10005041418390.29014-100000@propylaea.anduin.com>
References: <200005042111.RAA24006@ll.mit.edu>
X-SW-Source: 2000-05/msg00025.html
Content-length: 1778

And i don't
Breakpoint 1, main () at a.c:11
11        cout << "1\n";
Current language:  auto; currently c++
(gdb) p tt
tt               tteesstt11(int)  ttyname
(gdb) p tteesstt11(1)
------ Arg is int [7], parm is int [7]
Overloaded function instance tteesstt11(int) # of parms 1
...Badness @ 0 : 0
...Badness @ 1 : 0
Overload resolution champion is 0, ambiguous? 0

$1 = 4
(gdb)                


I can almost guarantee this is not a gdb bug.
Compiled with both dwarf2 debug info, and stabs debug info, it works fine
on BeOS and linux.

On Thu, 4 May 2000, David Cogen wrote:

> > Try adding a line or three to main that do nothing.
> 
> Like this?
> 
> #include <iostream>
> 
> int tteesstt11 (int)
> {
>   cerr << "\n";
>   return 4;
> }
> 
> int main ()
> {
>   cout << "1\n";
>   cout << "1\n";
>   cout << "1\n";
>   cout << "1\n";
>   cout << "1\n";
>   cout << "1\n";
>   cout << "1\n";
>   cout << "1\n";
>   cout << "1\n";
>   cout << "1\n";
>   cout << "1\n";
>   cout << "1\n";
>   cout << "1\n";
>   cout << "1\n";
>   cout << "1\n";
>   cout << "1\n";
>   cout << "1\n";
>   cout << "1\n";
>   cout << "1\n";
>   cout << "1\n";
>   cout << "1\n";
>   cout << "1\n";
>   cout << "1\n";
>   cout << "1\n";
>   cout << "1\n";
>   cout << "1\n";
>   cout << "1\n";
>   cout << "1\n";
>   cout << "1\n";
>   cout << "1\n";
>   cout << "1\n";
>   cout << "1\n";
>   cout << "1\n";
>   cout << "1\n";
>   cout << "1\n";
>   cout << "1\n";
>   cout << "1\n";
>   cout << "1\n";
>   cout << "1\n";
>   cout << "1\n";
>   cout << "1\n";
>   cout << "1\n";
>   cout << "1\n";
>   cout << "1\n";
>   cout << "1\n";
>   cout << "1\n";
> }
> 
> 
> I set my break on the first cout in main. When I print tteesstt11(1) I still
> get the debugger seg violation.
> 
> -- DavidC
> 

Re: auto-solib-add for "attach" as well as "run"

[Christopher Blizzard]

Michael Elizabeth Chastain wrote:
> 
> I have an enhancement request where a gdb user wants the
> "auto-solib-add" flag to work with the "attach" command as well
> as the "run" command.
> 
> Superficially, this looks like an entirely reasonable thing to do.
> "run" and "attach" are different in how they handle processes,
> but ought to work the same for the whole symbol-handling side of
> the debugger.
> 
> Can anyone point out any gotchas or drawbacks if I just go ahead
> and make "attach" honor the "auto-solib-add" flag?

In what sense does it not work now?  I can attach to a process with
auto-solib-add to both 0 and 1 and it works in both cases as I would
expect.

--Chris

-- 
------------
Christopher Blizzard
http://people.redhat.com/blizzard/
He who lives by the sword, should go out and get himself a really
nice sword.
------------
From muller@cerbere.u-strasbg.fr Fri May 05 01:10:00 2000
From: Pierre Muller <muller@cerbere.u-strasbg.fr>
To: gdb-patches@sourceware.cygnus.com, gdb@sourceware.cygnus.com
Subject: Pascal support patches status.
Date: Fri, 05 May 2000 01:10:00 -0000
Message-id: <200005050821.KAA18195@cerbere.u-strasbg.fr>
X-SW-Source: 2000-05/msg00027.html
Content-length: 491

 I added a patch request some time ago already about
adding Pascal language support in GDB.

  I was told that this would have to wait after 5.0 is released.

But as there is a 5.0 branch now, can we start considering my patches ??? 

  I can't find any link to the patch database ???
Is this database obsolete ??


Pierre Muller
Institut Charles Sadron
6,rue Boussingault
F 67083 STRASBOURG CEDEX (France)
mailto:muller@ics.u-strasbg.fr
Phone : (33)-3-88-41-40-07  Fax : (33)-3-88-41-40-99
From ac131313@cygnus.com Fri May 05 03:41:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Pierre Muller <muller@cerbere.u-strasbg.fr>
Cc: gdb-patches@sourceware.cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: Pascal support patches status.
Date: Fri, 05 May 2000 03:41:00 -0000
Message-id: <3912A4EC.1305F86B@cygnus.com>
References: <200005050821.KAA18195@cerbere.u-strasbg.fr>
X-SW-Source: 2000-05/msg00028.html
Content-length: 598

Pierre Muller wrote:
> 
>  I added a patch request some time ago already about
> adding Pascal language support in GDB.
> 
>   I was told that this would have to wait after 5.0 is released.
> 
> But as there is a 5.0 branch now, can we start considering my patches ???

Certainly. Since they are listed in the TODO I don't expect to miss them
for 5.1.

>   I can't find any link to the patch database ???
> Is this database obsolete ??

That I don't know.  JimB?  From memory several problems were identified
and it was put on hold.
In the mean time I've been tracking things by ``hand''.

	Andrew
From cogen@ll.mit.edu Fri May 05 09:00:00 2000
From: David Cogen <cogen@ll.mit.edu>
To: dan@cgsoftware.com
Cc: kettenis@wins.uva.nl, gdb@sourceware.cygnus.com, cogen@poblano
Subject: Re: gdb seg violation during print command
Date: Fri, 05 May 2000 09:00:00 -0000
Message-id: <200005051556.LAA26727@ll.mit.edu>
References: <Pine.LNX.4.10.10005041418390.29014-100000@propylaea.anduin.com>
X-SW-Source: 2000-05/msg00029.html
Content-length: 390

> I can almost guarantee this is not a gdb bug.
> Compiled with both dwarf2 debug info, and stabs debug info, it works fine
> on BeOS and linux.

But a gdb seg violation is a gdb bug by definition, I would think.

If the bug is elsewhere than gdb should be able to report an error message,
not seg fault itself.

Do you have any insight as to where the bug would be? g++? SunOS?

-- DavidC
From dan@cgsoftware.com Fri May 05 09:49:00 2000
From: Daniel Berlin <dan@cgsoftware.com>
To: David Cogen <cogen@ll.mit.edu>
Cc: dan@cgsoftware.com, kettenis@wins.uva.nl, gdb@sourceware.cygnus.com, cogen@poblano.resnet.rochester.edu
Subject: Re: gdb seg violation during print command
Date: Fri, 05 May 2000 09:49:00 -0000
Message-id: <66st9c39.fsf@dynamic-addr-88-42.resnet.rochester.edu>
References: <200005051556.LAA26727@ll.mit.edu>
X-SW-Source: 2000-05/msg00030.html
Content-length: 523

David Cogen <cogen@ll.mit.edu> writes:


> > I can almost guarantee this is not a gdb bug.
> > Compiled with both dwarf2 debug info, and stabs debug info, it works fine
> > on BeOS and linux.
> 
> But a gdb seg violation is a gdb bug by definition, I would think.

Yes, if that bug still occurs.
:)

> 
> If the bug is elsewhere than gdb should be able to report an error message,
> not seg fault itself.

Right.
> 
> Do you have any insight as to where the bug would be? g++? SunOS?
It's very hard to say.

> 
> -- DavidC
From cogen@ll.mit.edu Fri May 05 12:49:00 2000
From: David Cogen <cogen@ll.mit.edu>
To: dan@cgsoftware.com
Cc: dan@cgsoftware.com, kettenis@wins.uva.nl, gdb@sourceware.cygnus.com, cogen@poblano
Subject: Re: gdb seg violation during print command (more info)
Date: Fri, 05 May 2000 12:49:00 -0000
Message-id: <200005051945.PAA17501@ll.mit.edu>
References: <66st9c39.fsf@dynamic-addr-88-42.resnet.rochester.edu>
X-SW-Source: 2000-05/msg00031.html
Content-length: 596

I just thought of something, and found an answer.

With tteesstt11 declared as
  int tteesstt11 (int)

if I do
   whatis tteesstt11 
I get
   type = int (void)
which I believe is wrong. So it is not surprising to me that when I do
   print tteesstt11(3)
gdb cannot resolve it.

I then changed the declaration to
  int tteesstt11 (int x)
and then when I do
  whatis tteesstt11
I get
  type = int (int)
which is correct. Now when I do
  print tteesstt11(3)
I get 4. Yay!

  int tteesstt11 (int)
and
  int tteesstt11 (int x)
should be indistinguishable as far as overloading, I believe.

-- DavidC