2

I want to test a exception handler function that I have written for an embedded system and want to write a test code that injects an access to memory that forbidden.

void Test_Mem_exception
    {
    __asm(
    "LDR R0, =0xA0100000\n\t"
    "MOV R1, 0x77777777\n\t"
    "STR R1, [R0,#0]"
);

This is the code I want to write that access memory location at 0xA010000. Somehow this does not seem a generic test code to me.

Is there a standard way of writing such test codes in C or C++. By Generic I mean a code that is independent of the memory map of the system that it runs on.

owenrumney
  • 1,520
  • 3
  • 18
  • 37
Bhargav Kinnal
  • 23
  • 2
  • 1
    Hardware exceptions are architecture specific, portable C code that will generate an exception on any platform is not feasible. It is also unnecessary, you simply write an appropriate test for the platform of interest. – Clifford Jan 23 '20 at 19:06
  • ... "for _each_ platform of interest" I meant. – Clifford Jan 23 '20 at 22:53
  • One possibility is to simply iterate a `volatile` pointer through the entire address range and de-reference it. If any address is invalid and such invalid access will generate an exception then you will hit it - eventually. It would probably still work (where it works at all), if you iterated in steps of 1K or 4K or even larger and would speed up the iteration. If you also misalign the address, on some platforms it will generate an exception immediately - though possibly a different exception than you intend. – Clifford Jan 23 '20 at 23:07

1 Answers1

5

I wouldn't use asm for this, simply use a pointer.

void Test_Mem_exception
{
  /* volatile, to suppress optimizing/removing the read statement */
  volatile int *ptr = 0xC0C0C0C0;
  int value = *ptr;
}

This won't always result to an exception, because reading from address 0 can be valid on some systems.

The same applies to any other address, there doesn't exist any address that will fail on all systems.

jeb
  • 78,592
  • 17
  • 171
  • 225
  • That will generate a runtime error because the language requires it, but it will not necessarily result in an exception. – Clifford Jan 23 '20 at 19:08
  • @Clifford What is a `runtime error`? I can't find this term in the Ansi-C standard. Perhaps [de-referencing a null pointer could be undefined behavior](https://stackoverflow.com/a/28483256/463115), but even that is still in discussion. And using `0` was only a sample (Okay, perhaps a bad one) – jeb Jan 23 '20 at 21:57
  • 1
    The clue is in the name - and error that occurs when the program is running rather then at compile time. De-referncing a NULL pointer is _always_ an error in C, but it only results in undefined behaviour - de-referencing a NULL pointer is never valid - even if address zero is valid - that just means you cannot use C code to read/write the data at address zero. Nothing in the C language requires an exception, which is why it cannot be guaranteed to solve the question. It is somewhat pedantic perhaps since in my opinion the question is ill-conceived in any event. – Clifford Jan 23 '20 at 22:30
  • @Clifford A NULL pointer can be defined with a different value than 0. And there are still excpetions where dereferencing is valid `The defined behavior can simply be "you may dereference the null pointer as long as the value is not accessed.` quote from [Johannes Schaub - litb](https://stackoverflow.com/questions/6793262/why-dereferencing-a-null-pointer-is-undefined-behaviour#comment8063506_6793423). But I changed the value to a less problematic value :-) – jeb Jan 24 '20 at 11:17
  • The NULL macro can be redefined, but a null pointer is always a null pointer C99 and C++ both guarantee that an integer value zero represents a null pointer - even if the machine dependent representation differs. Your modified solution is essentially the same as the OPs code. This demonstrates a C language solution, but not a single solution for all platforms. Perhaps that is what is required - it is at least not specific to a particular instruction set. – Clifford Jan 24 '20 at 13:22