Re: Status of Linuxthreads support in gdb 4.18?

Re: Status of Linuxthreads support in gdb 4.18?

[Jim Blandy]

> Can anyone say what is the current status of support for Threads on
> Linux in gdb 4.18?

It don't exist.

I added it to our Code Fusion product, and now I have to find time to
merge it into our main sources.
From jimb@cygnus.com Wed Jul 28 13:33:00 1999
From: Jim Blandy <jimb@cygnus.com>
To: Sekaran Nanja <snanja@cup.hp.com>
Cc: Rajiv Mirani <mirani@cup.hp.com>, Mike Vermeulen <mev@hpclhayb.cup.hp.com>, gdb@sourceware.cygnus.com
Subject: Re: Regarding Range Table
Date: Wed, 28 Jul 1999 13:33:00 -0000
Message-id: <np7lnk1q3k.fsf@zwingli.cygnus.com>
References: <37990D39.B393D61B@cup.hp.com> <np908343yh.fsf@zwingli.cygnus.com> <379CCBBD.6E3FC2F3@cup.hp.com> <npn1wi3m05.fsf@zwingli.cygnus.com> <379D1B3A.32B9121B@cup.hp.com>
X-SW-Source: 1999-q3/msg00113.html
Content-length: 2180

> Jim>It makes more sense to me to add your new info to the struct symbol
> Jim>itself, so that value_of_variable can check it and complain
> Jim>appropriately.  It would be nice to do it in a way which doesn't use
> Jim>much space if we don't have this kind of information for the symbol.
> 
> Jim>What do you think?

Sekaran> Yes. It makes sense to add this info. to struct symbol to
Sekaran> keep things clean but we lose the new info. for an alias
Sekaran> symbol containing multiple ranges (Ex: variable has the same
Sekaran> home in several distinct ranges.). I think it is better to
Sekaran> save these new info. in range_list struct. Please let me know
Sekaran> what do you think about this.

Oh, I see --- just as a given variable home is valid only in certain
code ranges, your critical assignment motion info applies only to
certain code ranges.  And the ranges for a critical assignment motion
record will usually be some arbitrary subset of the variable's home's
ranges.

So a structure like this would be sufficient:

struct symbol {
  ... contains address class and symbol value ...
  struct range_list *ranges;
  ...
};

struct range_list {
  CORE_ADDR start, end;
  
  unsigned int set_early : 1;
  unsigned int set_late : 1;
  unsigned int unknown : 1;

  int  comes_from_line;
  int  moved_to_line;

  struct range_list *next;
};

Is that enough to accurately represent all the information you have?
Does it seem to be a straightforward representation, or is it obscure?


Is it possible for both set_early and set_late to be true for a given
range?  It seems to me that set_late means that the variable is dead,
while set_early means that the variable is live, but not live in the
way one would expect from reading the source.  Aren't set_early,
set_late, and unknown all mutually exclusive conditions?  If that's
true, they should be represented with an enum, not as separate bits.

I think comes_from_line and moved_to_line should be CORE_ADDR's, not
line numbers.  The mapping between source location and code is already
represented elsewhere; we shouldn't mix it in here if we don't have
to.  We should convert them into line numbers when they are output.
From snanja@cup.hp.com Wed Jul 28 14:48:00 1999
From: Sekaran Nanja <snanja@cup.hp.com>
To: Jim Blandy <jimb@cygnus.com>
Cc: Rajiv Mirani <mirani@cup.hp.com>, Mike Vermeulen <mev@hpclhayb.cup.hp.com>, gdb@sourceware.cygnus.com
Subject: Re: Regarding Range Table
Date: Wed, 28 Jul 1999 14:48:00 -0000
Message-id: <379F7A7F.8A21C4D2@cup.hp.com>
References: <37990D39.B393D61B@cup.hp.com> <np908343yh.fsf@zwingli.cygnus.com> <379CCBBD.6E3FC2F3@cup.hp.com> <npn1wi3m05.fsf@zwingli.cygnus.com> <379D1B3A.32B9121B@cup.hp.com> <np7lnk1q3k.fsf@zwingli.cygnus.com>
X-SW-Source: 1999-q3/msg00114.html
Content-length: 3340

>>Is that enough to accurately represent all the information you have?
>>Does it seem to be a straightforward representation, or is it obscure?
Yes. This is what I have already started implementing.

>>Is it possible for both set_early and set_late to be true for a given
>>range?
No.

>> Aren't set_early,
>>set_late, and unknown all mutually exclusive conditions?
Yes.

>>If that's
>>true, they should be represented with an enum, not as separate bits.
Yes. I agree.

>>I think comes_from_line and moved_to_line should be CORE_ADDR's, not
>>line numbers.  The mapping between source location and code is already
>>represented elsewhere; we shouldn't mix it in here if we don't have
>>to.  We should convert them into line numbers when they are output.
I think either CODE_ADDR or line number  is fine for this information. Since
HP debug info. format  saves this info. as line number,  it is preferable to
save this info. as line number  so that additional processing is not required
for both saving as well as displaying.

Thanks,
Sekaran.


Jim Blandy wrote:

> > Jim>It makes more sense to me to add your new info to the struct symbol
> > Jim>itself, so that value_of_variable can check it and complain
> > Jim>appropriately.  It would be nice to do it in a way which doesn't use
> > Jim>much space if we don't have this kind of information for the symbol.
> >
> > Jim>What do you think?
>
> Sekaran> Yes. It makes sense to add this info. to struct symbol to
> Sekaran> keep things clean but we lose the new info. for an alias
> Sekaran> symbol containing multiple ranges (Ex: variable has the same
> Sekaran> home in several distinct ranges.). I think it is better to
> Sekaran> save these new info. in range_list struct. Please let me know
> Sekaran> what do you think about this.
>
> Oh, I see --- just as a given variable home is valid only in certain
> code ranges, your critical assignment motion info applies only to
> certain code ranges.  And the ranges for a critical assignment motion
> record will usually be some arbitrary subset of the variable's home's
> ranges.
>
> So a structure like this would be sufficient:
>
> struct symbol {
>   ... contains address class and symbol value ...
>   struct range_list *ranges;
>   ...
> };
>
> struct range_list {
>   CORE_ADDR start, end;
>
>   unsigned int set_early : 1;
>   unsigned int set_late : 1;
>   unsigned int unknown : 1;
>
>   int  comes_from_line;
>   int  moved_to_line;
>
>   struct range_list *next;
> };
>
> Is that enough to accurately represent all the information you have?
> Does it seem to be a straightforward representation, or is it obscure?
>
> Is it possible for both set_early and set_late to be true for a given
> range?  It seems to me that set_late means that the variable is dead,
> while set_early means that the variable is live, but not live in the
> way one would expect from reading the source.  Aren't set_early,
> set_late, and unknown all mutually exclusive conditions?  If that's
> true, they should be represented with an enum, not as separate bits.
>
> I think comes_from_line and moved_to_line should be CORE_ADDR's, not
> line numbers.  The mapping between source location and code is already
> represented elsewhere; we shouldn't mix it in here if we don't have
> to.  We should convert them into line numbers when they are output.

Re: Status of Linuxthreads support in gdb 4.18?

[Rok Papez]

Hi Michael Snyder, Kevin Buettner and Eric Bachalo.

First, I'd like to thank you all for helping me :-).



On Fri, 10 Sep 1999, Michael Snyder wrote:
> > > Can anyone say what is the current status of support for
> > > Threads on Linux in gdb 4.18?
> 
> Readers of this newsgroup may be happy to hear that
> this merge has been done, and the Linux thread support
> patch that has been floating around the net for some time
> will be a part of gdb 4.19 whenever that comes out.

I downloaded the 1999/11/16 snapshot of insight but it didn't compile becouse
of the missing file. As I need LinuxThreads and remote debugging support
(gdbserver), could someone please give me a hint what snapshot should I
donwload? If insight doesn't work.. what version of plain gdb would work?

Btw.: Are there any differences between insight and gdb snapshots in
functionality? I was under impression gdb and insight are almost identical
except for the GUI part.

---------

On Thu, 25 Nov 1999, Eric Bachalo wrote:

> There is not much if any thread support, I believe.  This may change in the
> future but no promises.

Is the patch Michael Snyder is talking about already aplied to the CVS (is it
in the snapshot I downloaded?) ? If not do you by any chance know where to get
it ? Or at least where to get pre-compiled gdb and/or insight and gdbserver for
intel linux ?

> I am don't know whether DDD has support to use GDB remote debugging I have not
> tried it.  If you like to use a GUI with GDB, may I suggest that you try
> Insight.  It is very closely linked with GDB and does support remote
> debugging.

I did try the insight 1999/11/16 version but it failed to compile with:

cd gdb
./configure --prefix=/opt/insight
make
and then make complains:
--
make: *** No rule to make target `../bfd/bfd.h', needed by `blockframe.o'. 
Stop.
--
The needed file doesn't exist.

gdbserver did compile, but I'm unsure if it works with gdb-4.17.0.14-1 (the
supposedly LinuxThreads enabled gdb version I ran into).


-- 
best regards,
Rok Papez.
From cgf@cygnus.com Mon Nov 29 09:05:00 1999
From: Chris Faylor <cgf@cygnus.com>
To: gdb@sourceware.cygnus.com
Subject: Minor change to dcache.c
Date: Mon, 29 Nov 1999 09:05:00 -0000
Message-id: <19991129120527.A6056@cygnus.com>
X-SW-Source: 1999-q4/msg00353.html
Content-length: 1270

I'm working on a project which would benefit from being able to
turn on dcache at initialization time, so I'd like to propose
the following patch which provides a method for enabling the
dcache state via a set_dcache_state() function call.

Any objections or comments?

-chris

Index: gdb/dcache.c
===================================================================
RCS file: /cvs/cvsfiles/devo/gdb/dcache.c,v
retrieving revision 2.25
diff -u -p -r2.25 dcache.c
--- dcache.c	1999/10/15 08:15:30	2.25
+++ dcache.c	1999/11/29 16:42:16
@@ -539,6 +539,12 @@ dcache_info (exp, tty)
 }
 
 void
+set_dcache_state (int what)
+{
+  dcache_enabled_p = what;
+}
+
+void
 _initialize_dcache ()
 {
   add_show_from_set
Index: gdb/dcache.h
===================================================================
RCS file: /cvs/cvsfiles/devo/gdb/dcache.h,v
retrieving revision 2.6
diff -u -p -r2.6 dcache.h
--- dcache.h	1999/07/07 23:51:05	2.6
+++ dcache.h	1999/11/29 16:42:16
@@ -48,4 +48,8 @@ int dcache_xfer_memory PARAMS ((DCACHE *
 
 /* Write the bytes at ADDR into the data cache and the remote machine. */
 int dcache_poke_block PARAMS ((DCACHE * cache, CORE_ADDR mem, char *my, int len));
+
+/* Turn dcache state on or off */
+void set_dcache_state (int);
+
 #endif /* DCACHE_H */
From daveg@maker.com Mon Nov 29 13:00:00 1999
From: David Golombek <daveg@maker.com>
To: gdb@sourceware.cygnus.com
Subject: Writing a new simulator
Date: Mon, 29 Nov 1999 13:00:00 -0000
Message-id: <21vh6lj9mo.fsf@seattle143.maker.com>
X-SW-Source: 1999-q4/msg00354.html
Content-length: 1389

I'm examining using the simulator code packaged with GDB for the basis
of a new simulator project.  I haven't seen much discussion here about
the simulator packages, but haven't seen any other lists that might be
appropriate.  If there is another list, please direct me towards it.
I've read through a fair bit of the existing code, and wanted to ask
some questions to make sure my assumptions are correct.

This work is for a new processor, to which I've already ported the
Binutils, GDB, and Gas.  This is for a 32bit processor with a lot of
special functional units, which are memory mapped.

1) It seems that using either the mips or the v850 code as an example
it the best bet, using the same igen framework that they use.  T/F?

2) Reading the igen source, as well as the code in 'common', is the
only existing documentation on igen.  T/F?

3) Is there a good "ramp-up" methodology for writing a simulator, or
do I need to write very large parts of it before its useful at all?
IE, are there some pieces that I can implement first to get at least a
simulator that will run, if not do anything, so that I can do
piecewise implementation?

4) Are there any mail archives or any discussion saved anywhere of the
previous simulator implementations?  Just to give me a heads up on
potential pit-falls, etc., that i may run into. 

Thanks in advance for any suggestions or pointers,
DaveG
From jason@cygnus.com Mon Nov 29 13:31:00 1999
From: Jason Merrill <jason@cygnus.com>
To: Mark Mitchell <mark@codesourcery.com>
Cc: per@bothner.com, gcc@gcc.gnu.org, gdb@sourceware.cygnus.com
Subject: Re: debugging inline functions
Date: Mon, 29 Nov 1999 13:31:00 -0000
Message-id: <u966ylyogs.fsf@yorick.cygnus.com>
References: <m2u2m766gs.fsf@magnus.bothner.com> <19991128135119Y.mitchell@codesourcery.com> <m2hfi62rqe.fsf@magnus.bothner.com> <19991128160007P.mitchell@codesourcery.com>
X-SW-Source: 1999-q4/msg00355.html
Content-length: 580

 Per> Still, that is a user-interface issue - i.e.
 Per> a gdb issue.  We should make sure the debug output emits
 Per> enough information so that the debugger can (in theory)
 Per> present the call/inline state clearly.  I agree that suggests
 Per> emiting the inlined callee's line numbers.  But we should
 Per> also emit some indication that the function *was* inlined.
 Per> Does dwarf2 have a defined way to do this?  If so, I'd like
 Per> Gcc to emit it.  -- --Per Bothner per@bothner.com

GCC already does emit it (in dwarf2).  GDB just doesn't use the information.

Jason
From martin@mira.isdn.cs.tu-berlin.de Mon Nov 29 15:30:00 1999
From: "Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de>
To: mark@codesourcery.com
Cc: per@bothner.com, gcc@gcc.gnu.org, gdb@sourceware.cygnus.com
Subject: Re: debugging inline functions
Date: Mon, 29 Nov 1999 15:30:00 -0000
Message-id: <199911292326.AAA00972@mira.isdn.cs.tu-berlin.de>
References: <m2u2m766gs.fsf@magnus.bothner.com> <19991128135119Y.mitchell@codesourcery.com> <m2hfi62rqe.fsf@magnus.bothner.com> <19991128160007P.mitchell@codesourcery.com>
X-SW-Source: 1999-q4/msg00356.html
Content-length: 249

> Now I see what you're saying.  I'm not sure I agree, but I see your
> point.

FWIW, I agree with Per here. It is quite annoying if the debugger
brings you from one inline function to another, and you can't see the
caller's code.

Regards,
Martin