MMU and vtable
 

How does the virtual table accessed in MMU based system?

Re: MMU and vtable
 

schand wrote:
> How does the virtual table accessed in MMU based system?
>
The question is too implementation specific. Try a group dedicated to
your environment or you compiler documentation.

--
Ian Collins.

Re: MMU and vtable
 

Ian Collins wrote:
> schand wrote:
> > How does the virtual table accessed in MMU based system?
> >
> The question is too implementation specific. Try a group dedicated to
> your environment or you compiler documentation.
>
> --
> Ian Collins.

I checked the compiler manual I could not locate the virtual table
implementation. My ARM hardware has MMU enabled and the OS process/task
is running in separate memory area(with MMU support). There is no
shared memory support. So I want to know if two process access the
derived class (virtual pointer) objects and how the virtual table is
shared between these processes. As per my understaning vtable is
stored in the data segment.

Re: MMU and vtable
 

what is your problem exactly? the data before your fork() will be
copied in both process.

schand wrote:
> Ian Collins wrote:
> > schand wrote:
> > > How does the virtual table accessed in MMU based system?
> > >
> > The question is too implementation specific. Try a group dedicated to
> > your environment or you compiler documentation.
> >
> > --
> > Ian Collins.
>
> I checked the compiler manual I could not locate the virtual table
> implementation. My ARM hardware has MMU enabled and the OS process/task
> is running in separate memory area(with MMU support). There is no
> shared memory support. So I want to know if two process access the
> derived class (virtual pointer) objects and how the virtual table is
> shared between these processes. As per my understaning vtable is
> stored in the data segment.

Re: MMU and vtable
 

schand wrote:
> Ian Collins wrote:
>
>>schand wrote:
>>
>>>How does the virtual table accessed in MMU based system?
>>>
>>
>>The question is too implementation specific. Try a group dedicated to
>>your environment or you compiler documentation.
>>
>
> I checked the compiler manual I could not locate the virtual table
> implementation. My ARM hardware has MMU enabled and the OS process/task
> is running in separate memory area(with MMU support). There is no
> shared memory support. So I want to know if two process access the
> derived class (virtual pointer) objects and how the virtual table is
> shared between these processes. As per my understaning vtable is
> stored in the data segment.
>
Please set you newsreader to trim signatures.

I don't know of any operating environment where two process can share
objects that use virtual methods.

--
Ian Collins.

Re: MMU and vtable
 

schand wrote:
> Ian Collins wrote:
>> schand wrote:
>>> How does the virtual table accessed in MMU based system?
>>>
>> The question is too implementation specific. Try a group dedicated
>> to your environment or you compiler documentation.
>>
>> --
>> Ian Collins.
>
> I checked the compiler manual I could not locate the virtual table
> implementation. My ARM hardware has MMU enabled and the OS
> process/task is running in separate memory area(with MMU support).
> There is no shared memory support. So I want to know if two process
> access the derived class (virtual pointer) objects and how the
> virtual table is shared between these processes. As per my
> understaning vtable is stored in the data segment.

That is two entirely different uses of the word 'virtual'. They are
not connected in any way.

The MMU handles hardware virtuals, while the vtable is entirely a
software thing (and optional at that).



Bo Persson

Re: MMU and vtable
 

Yes, I know virtual memeory management.

Support we have clas sB derived from Class with virtual functions. If
I understand correctly, compiler will create a virtual table for class
B in the data area and Class B will have a pointer to vtable. Support
Process A and Process B create object of type Class B, ow the vtable is
shared.

Ian Collins wrote:
> schand wrote:
> > Ian Collins wrote:
> >
> >>schand wrote:
> >>
> >>>How does the virtual table accessed in MMU based system?
> >>>
> >>
> >>The question is too implementation specific. Try a group dedicated to
> >>your environment or you compiler documentation.
> >>
> >
> > I checked the compiler manual I could not locate the virtual table
> > implementation. My ARM hardware has MMU enabled and the OS process/task
> > is running in separate memory area(with MMU support). There is no
> > shared memory support. So I want to know if two process access the
> > derived class (virtual pointer) objects and how the virtual table is
> > shared between these processes. As per my understaning vtable is
> > stored in the data segment.
> >
> Please set you newsreader to trim signatures.
>
> I don't know of any operating environment where two process can share
> objects that use virtual methods.
>
> --
> Ian Collins.

Re: MMU and vtable
 

Yes, I know virtual memory management.

Support we have class B derived from Class A which has virtual
functions. If I understand correctly, compiler will create a virtual
table for class B in the data area and Class B will have a pointer to
vtable. Suppose Process A and Process B create object of type Class B,
how the vtable is shared.?
Bo Persson wrote:
> schand wrote:
> > Ian Collins wrote:
> >> schand wrote:
> >>> How does the virtual table accessed in MMU based system?
> >>>
> >> The question is too implementation specific. Try a group dedicated
> >> to your environment or you compiler documentation.
> >>
> >> --
> >> Ian Collins.
> >
> > I checked the compiler manual I could not locate the virtual table
> > implementation. My ARM hardware has MMU enabled and the OS
> > process/task is running in separate memory area(with MMU support).
> > There is no shared memory support. So I want to know if two process
> > access the derived class (virtual pointer) objects and how the
> > virtual table is shared between these processes. As per my
> > understaning vtable is stored in the data segment.
>
> That is two entirely different uses of the word 'virtual'. They are
> not connected in any way.
>
> The MMU handles hardware virtuals, while the vtable is entirely a
> software thing (and optional at that).
>
>
>
> Bo Persson

Re: MMU and vtable
 

schand wrote:
>As per my understaning vtable is stored in the data segment.

Then what more do you want to know from the C++ newsgroup? How data
segment objects are loaded, and how their symbolic addresses are
resolved into run-time references, has absolutely nothing to do with
C++ and everything to do with the platform you are using.

Re: MMU and vtable
 

schand wrote:

Top posting corrected, please don't!
>
> Ian Collins wrote:
>
>>schand wrote:
>>
>>>Ian Collins wrote:
>>>
>>>
>>>>schand wrote:
>>>>
>>>>
>>>>>How does the virtual table accessed in MMU based system?
>>>>>
>>>>
>>>>The question is too implementation specific. Try a group dedicated to
>>>>your environment or you compiler documentation.
>>>>
>>>
>>>I checked the compiler manual I could not locate the virtual table
>>>implementation. My ARM hardware has MMU enabled and the OS process/task
>>>is running in separate memory area(with MMU support). There is no
>>>shared memory support. So I want to know if two process access the
>>>derived class (virtual pointer) objects and how the virtual table is
>>>shared between these processes. As per my understaning vtable is
>>>stored in the data segment.
>>>
>>
>>Please set you newsreader to trim signatures.
>>
>>I don't know of any operating environment where two process can share
>>objects that use virtual methods.
>>
> Yes, I know virtual memeory management.
>
> Support we have clas sB derived from Class with virtual functions. If
> I understand correctly, compiler will create a virtual table for class
> B in the data area and Class B will have a pointer to vtable. Support
> Process A and Process B create object of type Class B, ow the vtable is
> shared.

Please set you newsreader to trim signatures.

No, it isn't, unless all your processes share the same address space.
As others have said, you appear to be confusing virtual memory for
virtual inheritance.

--
Ian Collins.