Posted for a customer:
A customer has asked the following question on shared objects:
When a shared object is loaded into memory by the OS and when
the shared object is unloaded from memory are there corresponding
functions in the so that get called? For instance in a Windows DLL
when the dll is first loaded a call to DllMain is made by the os
(Windows). This gives the creator a chance to initialized the DLL for
use. When the dll is unloaded another function is called by the OS
(forget the name). We have a shared object that is our display driver
that regardless of what happens when the shared object is unloaded I
want to put the video card back in a state that the rest of the system
can use it.
The customer is currently using RTP Patch A.
As mentioned in the thread that this customer posted, they are
trying to do a cleanup when hitting a SIGSEGV. They will have
to register a signal handler, run their cleanup routine, and
then exit.
Jeffrey Schaffer <jpschaffer@qnx.com> wrote:
Posted for a customer:
A customer has asked the following question on shared objects:
When a shared object is loaded into memory by the OS and when
the shared object is unloaded from memory are there corresponding
functions in the so that get called? For instance in a Windows DLL
when the dll is first loaded a call to DllMain is made by the os
(Windows). This gives the creator a chance to initialized the DLL for
use. When the dll is unloaded another function is called by the OS
(forget the name). We have a shared object that is our display driver
that regardless of what happens when the shared object is unloaded I
want to put the video card back in a state that the rest of the system
can use it.
The customer is currently using RTP Patch A.
–
cburgess@qnx.com
Jeffrey Schaffer <jpschaffer@qnx.com> wrote:
Posted for a customer:
A customer has asked the following question on shared objects:
When a shared object is loaded into memory by the OS and when
the shared object is unloaded from memory are there corresponding
functions in the so that get called? For instance in a Windows DLL
when the dll is first loaded a call to DllMain is made by the os
(Windows). This gives the creator a chance to initialized the DLL for
use. When the dll is unloaded another function is called by the OS
(forget the name). We have a shared object that is our display driver
that regardless of what happens when the shared object is unloaded I
want to put the video card back in a state that the rest of the system
can use it.
I am not aware of any equivalent entry points under QNX.
However, with respect to graphics drivers:
The first functions to be called for a graphics driver dll are
the devg_get* functions. These are used to obtain the remainder
of the drivers entry points. They typically wouldn’t touch any
hardware, or do anything besides fill in the function tables.
The first function to perform any initialisation is usually
the mode-switchers “init” entry point. The mode switchers
“init” entry point is guaranteed to be called before the
“init” entry point of any other module gets called (and
before any other mode-switcher entry point is called).
Similarly, when the dll gets unloaded, the “fini” entry
points of the various modules will be called. The mode-switcher
module’s “fini” entry point is guaranteed to be the last one
called.
So they should restore the device state in the mode-switchers
“fini” routine.
David Donohoe <ddonohoe@qnx.com> wrote:
Jeffrey Schaffer <> jpschaffer@qnx.com> > wrote:
Posted for a customer:
A customer has asked the following question on shared objects:
When a shared object is loaded into memory by the OS and when
the shared object is unloaded from memory are there corresponding
functions in the so that get called? For instance in a Windows DLL
when the dll is first loaded a call to DllMain is made by the os
(Windows). This gives the creator a chance to initialized the DLL for
use. When the dll is unloaded another function is called by the OS
(forget the name). We have a shared object that is our display driver
that regardless of what happens when the shared object is unloaded I
want to put the video card back in a state that the rest of the system
can use it.
I gather from another thread that the customer was also asking
about what happens if the program were to crash.
io-graphics registers a handler to catch SIGSEGV, SIGBUS SIGFPE etc.
If some part of the graphics driver framework were to crash,
io-graphics would catch the condition in its signal handler,
and call the driver dll’s “fini” entry points, in order to clean
things up (which on a desktop x86 system should result in a return
to text mode, if the “fini” entry points do everything right, and
whatever caused the crash in the first place has not caused too
much damage).
I am not aware of any equivalent entry points under QNX.
However, with respect to graphics drivers:
The first functions to be called for a graphics driver dll are
the devg_get* functions. These are used to obtain the remainder
of the drivers entry points. They typically wouldn’t touch any
hardware, or do anything besides fill in the function tables.
The first function to perform any initialisation is usually
the mode-switchers “init” entry point. The mode switchers
“init” entry point is guaranteed to be called before the
“init” entry point of any other module gets called (and
before any other mode-switcher entry point is called).
Similarly, when the dll gets unloaded, the “fini” entry
points of the various modules will be called. The mode-switcher
module’s “fini” entry point is guaranteed to be the last one
called.
So they should restore the device state in the mode-switchers
“fini” routine.