Re: Pointer parameter in function optimized out - incorrectly

[Kalle Olavi Niemitalo <kon at iki dot fi>]

James Kuyper <James.R.Kuyper@NASA.gov> writes:

> At optimization level 2, as indicated by the following output from gdb,
> scan_time is optimized out of the function call interface for
> process_a_scan(). The address for SD_start_time is simply
> passed directly to compute_SD_start_time(). The problem is that it is
> sometimes the incorrect address. In this particular case, 33 scans were
> processed without a hitch, and then it failed for the 34th:

IIRC, "<value optimized out>" can mean that the value was passed
to the function with the usual mechanism, but the function no
longer needs it at that point, so the compiler has reused the
register or memory location for some other purpose.
I am thus not convinced that any link-time optimization occurred.

Can you reproduce the SIGSEGV with the same input?
If so, you could try breaking at the 34th entry to process_a_scan
and checking whether the pointer is correct at that time.
If you have a buffer overflow or underflow that corrupts the
pointer in memory, then you might be able to track that down with
a watchpoint in GDB, perhaps coupled with breakpoints that run
commands to set the watchpoint on entry to a function and remove
it again when the function is about to return.