From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rok Papez To: gdb@sourceware.cygnus.com Subject: Re: Status of Linuxthreads support in gdb 4.18? Date: Mon, 29 Nov 1999 05:47:00 -0000 Message-id: <99112914361602.00578@Strader.home> References: <379EA3DB.58B72C0A@albatross.co.nz> <37D82EA1.260A@cygnus.com> X-SW-Source: 1999-q4/msg00352.html 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 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 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 To: Mark Mitchell 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: References: <19991128135119Y.mitchell@codesourcery.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" 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: <19991128135119Y.mitchell@codesourcery.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