Re: Debugging with thread(s)

Re: Debugging with thread(s)

[Claude Robitaille]

Hi,

I could not find Lu's directory on VA's ftp site. However, I found 4.18-10
on rufus. The change log says that gdb is now thread safe.

I donwloaded the SRPMS but it contains 3 ...tar.bz2 files. I do not know
what compression format is bz2. I tried gunzip and unzip but it did not
worked. Anybody knows what format it is?

Claude

PS Once I have compiled it, what is the best way to propagate this new
version? And how? 

On Tue, 7 Dec 1999, Kevin_Hendricks wrote:

> Hi,
> 
> I use gdb to debug native threads all of the time for the jdk. You have to get a 
> version of gdb that actually has thread support and you have to have a version 
> of gdb that understands the real time signals (since they are used by both the 
> JDK and linuxthreads).
> 
> The best way to get a real working gdb is to go the H.J.Lu's ftp site at VA 
> Research (I don't remember the url right off hand but I am sure you can find it 
> if you look) and grab his latest linux specific SRPM for gdb (it is a 4.17.X) 
> and rebuild it under PPC.
> 
> This will allow you to work with real time signals and debug linuxthreads code.
> 
> Kevin
> 
> --
> Kevin B. Hendricks
> Associate Professor of Operations and Information Technology
> Richard Ivey School of Business, University of Western Ontario
> London, Ontario  N6A-3K7  CANADA   
> khendricks@ivey.uwo.ca, (519) 661-3874, fax: 519-661-3959
> 
> 


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Debugging with thread(s)

[Martin Costabel]

Claude Robitaille wrote:
> 
> Hi,
> 
> I could not find Lu's directory on VA's ftp site. However, I found 4.18-10
> on rufus. The change log says that gdb is now thread safe.

Is anything wrong with Franz Sirl's gdb-4.18-4c in his directory at
dev.linuxppc.org?

--
Martin

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Debugging with thread(s)

[Marcus Sundberg]

Tony Mantler <eek@escape.ca> writes:

> At 6:59 PM -0600 12/7/99, Claude Robitaille wrote:
> >I donwloaded the SRPMS but it contains 3 ...tar.bz2 files. I do not know
> >what compression format is bz2. I tried gunzip and unzip but it did not
> >worked. Anybody knows what format it is?
> 
> >From <http://sourceware.cygnus.com/bzip2/>:
> 
> [...snip...]
> What is bzip2?
> 
> bzip2 is a freely available, patent free (see below), high-quality data
> compressor. It typically compresses files to within 10% to 15% of the best
> available techniques, whilst being around twice as fast at compression and
> six times faster at decompression.
> [...snip...]
> 
> I actually found it to be a bit slower than gzip on my 68k boxes, but it
> probably optimizes better on PPC or x86.

The text is referring to "the best available techniques", not gzip.
bzip2 is signifficantly slower than gzip on all platforms I've tried
it on.

//Marcus
-- 
Signature under construction, please come back later.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: What's MMU context?

[Dan Malek]

Wang Yong wrote:
> 
> as the source code of linuxPPC, there is a global variable named
> next_mmu_context which is increased by one at each time of create a new
> process. what does this mean and what is mmu context?


I intened to use it on the 8xx processors, as they have an address
space id that allows a TLB optimization so you don't have to
invalidate the entire TLB on context switches.  I assume the
MIPS folks use it as well, since that is where I first used
such an optimization (in an OS other than Linux).  Unfortunately,
the ratio of entries to ASIDs is wrong for my original MIPS-like
algorithm to work, and I never got around to writing something
new.

This was already part of the Linux/PPC port when I started the 8xx
work, and I don't know if other processors use it or if it was
just part of the generic port that was maintained.


	-- Dan

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Debugging with thread(s)

[Claude Robitaille]

Hi,

anybody has tried to debug an application that uses thread
using GUI frontend to gdb? I have try code_medic and kdbg
but in both cases, when I execute pthread_create I get an
unknown signal and the breakpoints I set in the called
(created) thread do not activate. I might have problem
with my code but I tried to put a while(1); right after
a printf just at the beginning of the created thread. I
put a breakpoint on the printf but I do get an ouput
in the program output window. (I also put a while(1);
in the calling code, just to make sure). I think, somehow,
the GUIs do not support threads. Any idea?

Claude


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Debugging with thread(s)

[Frank McPherson]

Claude Robitaille wrote:

> anybody has tried to debug an application that uses thread
> using GUI frontend to gdb? ... I execute pthread_create I get an
> unknown signal and the breakpoints I set in the called
> (created) thread do not activate. 

I get the same behavior when using gdb without any frontend.  Pthreads
seems to use real-time signals (32 and higher), and though the
documentation for gdb indicates it should be able to handle them, I
haven't been able to get it to work.  I posted a query about this
yesterday called "real-time signals, gdb".    

It has been suggested to me by another list member that the signal
handling code in the Linux kernel may be seriously deficient, and
aggrevating if not outright causing this problem.  I haven't had a
chance yet to look and see if that's the case. 

Has anyone else had success debugging threads with gdb? 

-Frank

-- 
Frank H. McPherson IV
W118 Embedded Solutions Team
The MITRE Corporation
703-883-5404

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/