LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - General (https://www.linuxquestions.org/questions/linux-general-1/)
-   -   Segmentation fault with rdtsc, but not in debug mode of gcc 4.7 (https://www.linuxquestions.org/questions/linux-general-1/segmentation-fault-with-rdtsc-but-not-in-debug-mode-of-gcc-4-7-a-4175442018/)

CelticFiddler 12-18-2012 02:28 PM
Segmentation fault with rdtsc, but not in debug mode of gcc 4.7
 
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:
Code:
unsigned long hi, lo;
__asm__ __volatile__ ("cpuid;rdtsc" : "=a"(lo), "=d"(hi)):
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:

Code:
std::cerr << "TSC read complete" << std::endl; // <== this is output
std::cerr << "now incrementing counter" << std::endl; // <== never gets here
I'm not sure this is TSC related. Could be just general I/O problem?

I'm using gcc 4.7.

Any clues?

pan64 12-19-2012 06:56 AM
is this code multithreaded? is it threadsafe? do you have a coredump? have you tried to analyze it?

CelticFiddler 12-19-2012 02:31 PM
Quote:
Originally Posted by pan64 (Post 4852781)
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.

pan64 12-20-2012 04:48 AM
inp_b may cause segfault: http://linux.about.com/library/cmd/blcmdl2_inb_p.htm

CelticFiddler 12-20-2012 08:35 AM
Quote:
Originally Posted by pan64 (Post 4853563)
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.

pan64 12-20-2012 08:51 AM
If you can try valgrind it can help you to locate such problems also.


All times are GMT -5. The time now is 11:27 PM.