Tlb Load Exception!
RamSen
We are using Tornado212 MIPS, vxWorks 5.4.2. The TLB Load
exception is happening while accessing NULL pointer ie *(0x0) or
strcmp (0,""). But the Tornado221 PPC doesn't have this problem; it is
simply returning zero.
Though the NULL pointer access is invalid; I want to stop the
Exception and reboot because of that exception.
Is there any way to fix / handle this in MIPS?
Thanks & Regards,
Ramsenthil.
nois...@gmail.com
It's my understanding that page 0 is never mapped on the MIPS
architecture and doing an access there always causes a trap. I think
on PPC, the exception vector table lives in page 0, so it is mapped.
However this does not mean that a NULL pointer dereference is not a
bug on PPC: it just means that instead of an explicit trap, you get
silent data corruption. The MIPS case is actually preferable since it
exposes the problem immediately.
In any case, the correct thing to do is _not_ to ignore the trap.
There is no legitimate reason to have such invalid pointer use in your
code: it is a sign of a bug, and you need to fix it instead of
sweeping it under the rug. The trap generated on MIPS is actually
useful for debugging exactly this sort of problem (the exception info
should include the program counter value of the instruction that
triggered the trap).
-Bill
RamSen
Thanks Bill! I do understand, NULL pointer dereference is illegal. We
are doing porting from PPC to MIPS. We are facing lot of exceptions
due to poor coding. We almost corrected everthing. For saferside, the
client wants to have the support for NULL access...
Is there any way to map Page 0 in MIPS? Or atleast some other dummy
mapping for address 0x0?
Where could we find these mapping in VxWorks 5.4.2?
Thanks & Regards,
Ramsenthil.
nois...@gmail.com
Tell your client he's wrong! This is not the "saferside!" Ignoring
these traps is EXTREMELY UNSAFE! You must fix the code! You should
consider it a miracle that the PPC-based device running this code did
not crash left and right!
People use VxWorks in many applications where safety is critical, such
as industrial automation and medical diagnosis/therapy machines. Bugs
of this nature (wild pointers) can cause all kinds of unpredictable
failures, and with safety critical systems an unpredictable failure
could lead to injury or death. I sincerely hope that your client's
device is not of this nature, because if it is they're advocating
putting their customers at a terrible risk.
"Supporting NULL access" is not a feature. It does not immunize your
code against crashes. It just makes you vulnerable to more
unpredicable crashes in the future. The fact that you got away with it
on PPC is truly unfortunate, particularly since it seems to have given
you (and the client) the idea that it was okay to deploy buggy code.
Here, the MIPS processor is being kind enough to show you exactly
where the bugs are: pay attention to what it's telling you and fix the
problems instead of ignoring them. Even if your target device is not
safety-critical, deliberately trying to make it ok to have NULL
pointer dereferences in your code is very poor practice.
You are also going to find that VxWorks/MIPS is not the only case
where the NULL pointer dereferences immediately produce a fatal
runtime error. With VxWorks 6.x using RTPs (i.e. protection domains),
you would have also gotten a trap no matter which architecture you
used. With UNIX, you would have gotten a segmentation fault.
> Is there any way to map Page 0 in MIPS? Or atleast some other dummy
> mapping for address 0x0?
>
> Where could we find these mapping in VxWorks 5.4.2?
Even if I knew, I would not tell you. (Note that there is a documented
way of creating custom exception handlers, but I'm not going to go
into it here since I think it would only be an even bigger bullet with
which to shoot yourself in the foot.) What you really must do is:
- Fix all the NULL pointer bugs exposed by the MIPS arch
- Institute a rigorous testing process
- Do a full formal review of the code
I know you think this may be a lot of work. I know it may interfere
with your deadlines. I know your client may not be thrilled at the
prospect of the extra costs and scheduling delays this may incurr. But
please, I implore you: fix the damn code.
-Bill
> Thanks & Regards,
> Ramsenthil.
RamSen
>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -
Thanks a lot for your advices. I will try to follow all your
suggestions.