Skip to contentSkip to conversation

What's MMU context?

DISCUSSION Wang Yong 4 participants 5 messages Oct 27, 1999 – Dec 12, 1999

lore
Share & tools
lore

Wang Yong

author
#0 lore raw

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/

#1 lore raw
Quoted 4 lines · Wang Yong

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/

#2 lore raw

Debugging with thread(s)

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/

#3 lore raw

Re: Debugging with thread(s)

Quoted 4 lines · Claude Robitaille

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

Signature · 6 lines
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/
#4 lore raw

Thread and malloc

In reply to Dan Malek

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/