I was fooling around a bit with getting timing from the TSC using gcc 4.7 on a 1.8GHz system. I wanted to find the overhead for various operations (such as just reading the TSC).

Code:
This runs fine in debug mode, but give a segfault in any non-debug mode.

What's really strange is that the segfault occurs two (C++) lines later, in code that looks like this:

I'm not sure this is TSC related. Could be just general I/O problem?

I'm using gcc 4.7.

Any clues?

is this code multithreaded? is it threadsafe? do you have a coredump? have you tried to analyze it?

Single threaded. The entire embedded system is intended to be single-threaded by design.
Probably not threadsafe.
No coredump file produced, just segfault and abort.
I spent some time trying to track down where the exact location of the segfault was, but that's as far as I've gotten so far. I recall seeing a requirement for certain gcc settings being required for using inb_p(), & outb_p(), so I will be revisiting that to see how to set the compiler options in u++/TheIDE.

inp_b may cause segfault: http://linux.about.com/library/cmd/blcmdl2_inb_p.htm

I know about that one. In addition to the information on that page, you must use ioperm on port 0x80 also. If you don't, any of the "_p" I/O instructions will segfault, even in debug mode. I found out about that through a question here -- I don't recall ever seeing that tidbit in any documentation.

The problem I'm having is that the program does *NOT* segfault in debug mode, but will segfault if I compile without debug.

I am using TheIDE/Upp for development, and I'm not 100% certain what options are included in non-debug builds. However, the only options that I see that are recommended for use with the I/O instruction are -O and -O2, which I think are turned *OFF* for the debug builds. So the mystery remains. I'm ok for now, but there will come a time when I have to get this to run in a non-debug mode.

If you can try valgrind it can help you to locate such problems also.