* What's MMU context?
@ 1999-10-27 11:50 Wang Yong
1999-10-27 15:55 ` Dan Malek
0 siblings, 1 reply; 8+ messages in thread
From: Wang Yong @ 1999-10-27 11:50 UTC (permalink / raw)
To: linux-ppc; +Cc: linuxppc embedded mail list
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? it appears there
is not any mmu context in i386.
Wang
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: What's MMU context?
1999-10-27 11:50 What's MMU context? Wang Yong
@ 1999-10-27 15:55 ` Dan Malek
1999-12-07 2:58 ` Debugging with thread(s) Claude Robitaille
1999-12-12 0:00 ` Thread and malloc Claude Robitaille
0 siblings, 2 replies; 8+ messages in thread
From: Dan Malek @ 1999-10-27 15:55 UTC (permalink / raw)
To: wung_y; +Cc: linux-ppc, linuxppc embedded mail list
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/
^ permalink raw reply [flat|nested] 8+ messages in thread
* Debugging with thread(s)
1999-10-27 15:55 ` Dan Malek
@ 1999-12-07 2:58 ` Claude Robitaille
1999-12-07 13:14 ` Frank McPherson
1999-12-12 0:00 ` Thread and malloc Claude Robitaille
1 sibling, 1 reply; 8+ messages in thread
From: Claude Robitaille @ 1999-12-07 2:58 UTC (permalink / raw)
To: linuxppc-dev
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/
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Debugging with thread(s)
1999-12-07 2:58 ` Debugging with thread(s) Claude Robitaille
@ 1999-12-07 13:14 ` Frank McPherson
0 siblings, 0 replies; 8+ messages in thread
From: Frank McPherson @ 1999-12-07 13:14 UTC (permalink / raw)
To: Claude Robitaille; +Cc: linuxppc-dev
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/
^ permalink raw reply [flat|nested] 8+ messages in thread
* Thread and malloc
1999-10-27 15:55 ` Dan Malek
1999-12-07 2:58 ` Debugging with thread(s) Claude Robitaille
@ 1999-12-12 0:00 ` Claude Robitaille
1 sibling, 0 replies; 8+ messages in thread
From: Claude Robitaille @ 1999-12-12 0:00 UTC (permalink / raw)
To: linuxppc-dev
Hi,
I am getting segmentation faults in malloc when using threads. I have
updated my kernel to 2.2.14pre6, gcc, gdb (to 4.18), etc. I try both
code_medic and ddd. Is malloc thread safe? A book I am reading indicates
that some malloc are thread safe and some others are not. But the book
is not Linux specific.
The Web pages I have found so far are pretty old and mostly talk about
LinuxThread (for 2.0.X). The man pages for malloc, etc. do not indicate
anything about thread friendlyness... (and they would probably out of date
anyway....). Is there a good place for information about thread in Linux?
Anyboady has a idea why I an getting faults in malloc?
Thanks
Claude
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 8+ messages in thread
[parent not found: <0FMD0095OJDI5C@falla.videotron.net>]
* Re: Debugging with thread(s)
[not found] <0FMD0095OJDI5C@falla.videotron.net>
@ 1999-12-08 0:59 ` Claude Robitaille
1999-12-08 8:38 ` Martin Costabel
[not found] ` <v04003a00b47368afb81b@[216.81.20.221]>
1 sibling, 1 reply; 8+ messages in thread
From: Claude Robitaille @ 1999-12-08 0:59 UTC (permalink / raw)
To: linuxppc-dev, Kevin_Hendricks; +Cc: Frank McPherson
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/
^ permalink raw reply [flat|nested] 8+ messages in thread[parent not found: <v04003a00b47368afb81b@[216.81.20.221]>]
* Re: Debugging with thread(s)
[not found] ` <v04003a00b47368afb81b@[216.81.20.221]>
@ 1999-12-08 13:14 ` Marcus Sundberg
0 siblings, 0 replies; 8+ messages in thread
From: Marcus Sundberg @ 1999-12-08 13:14 UTC (permalink / raw)
To: Tony Mantler; +Cc: Claude Robitaille, linuxppc-dev
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/
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~1999-12-12 0:00 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
1999-10-27 11:50 What's MMU context? Wang Yong
1999-10-27 15:55 ` Dan Malek
1999-12-07 2:58 ` Debugging with thread(s) Claude Robitaille
1999-12-07 13:14 ` Frank McPherson
1999-12-12 0:00 ` Thread and malloc Claude Robitaille
[not found] <0FMD0095OJDI5C@falla.videotron.net>
1999-12-08 0:59 ` Debugging with thread(s) Claude Robitaille
1999-12-08 8:38 ` Martin Costabel
[not found] ` <v04003a00b47368afb81b@[216.81.20.221]>
1999-12-08 13:14 ` Marcus Sundberg
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).