Cortex M3 GPIO Interrupt won’t trigger

As you've discovered, handling counter overflow with an interrupt handler is tricky and race-prone. Even with your priority boost, you'll get the wrong answer if interrupts are disabled while you read the counter. There's a much simpler technique which works if you're not reading the clock from interrupt context (note that I'm using the DWT cycle counter here, which is built into the processor thus fast and simple):

uint64_t last_cycle_count_64 = 0;

// Call at least every 2^32 cycles (every 59.6 seconds @ 72 MHz).
// Do not call from interrupt context!
uint64_t GetCycleCount64() {
  last_cycle_count_64 += DWT->CYCCNT - (uint32_t)(last_cycle_count_64);
  return last_cycle_count_64;
}

If you need to call it from interrupt context (or with a preemptive OS):

volatile uint64_t last_cycle_count_64 = 0;

// Call at least every 2^32 cycles (every 59.6 seconds @ 72 MHz).
uint64_t GetCycleCount64() {
  uint32_t primask;
  asm volatile ("mrs %0, PRIMASK" : "=r"(primask));
  asm volatile ("cpsid i");  // Disable interrupts.
  int64_t r = last_cycle_count_64;
  r += DWT->CYCCNT - (uint32_t)(r);
  last_cycle_count_64 = r;
  asm volatile ("msr PRIMASK, %0" : : "r"(primask));  // Restore interrupts.
  return r;
}

You may need to enable the cycle counter first:

DWT->CYCCNT |= DWT_CTRL_CYCCNTENA_Msk;  // Set bit 0.

The interrupt mechanism is described in the ARM Architectural Reference Manual and/or the Technical Reference Manual, both are available at infocenter.arm.com. Then there is some info that you need from the chip vendors datasheet (arm does not make chips they make processor cores that chip vendors buy and use). so unlike the traditional arm with an irq and fiq input the cortex-m3 has a bunch of interrupt inputs and you have to figure out where the vendor wired your interrupt.

The way the cortex-m's work you have an interrupt vector table which includes addresses for the routines for each of the interrupts/exceptions. (described in the ARM ARM and/or ARM TRM) reset happens to be one of those so you already have that implemented, the first four bytes are loaded into the stack pointer then the next four are the address for reset then it goes into exceptions and interrupts which are core specific (the cortex-m3 and cortex-m4 and cortex-m0 dont necessarily have the exact same list and certainly each vendor or model may have different things wired up).

Then of course you have to enable interrupts on the vendor side, the peripheral, perhaps an interrupt controller then on the arm side.

The nice thing about the cortex-m design is that the hardware conforms to the arm calling convention (it preserves registers for you on the stack, etc), you can place the address to a C function right in the vector table, there is no longer a need to wrap your C interrupt handler with assembly or use compiler specific directives to get the compiler to wrap your code for handling interrupts.

I generally recommend that you start by polling your way toward the core, if possible poll the peripheral interrupt status to see if it fired, then enable that status to go on to the next level, poll that, then enable that eventually to the edge of the core where you can usually poll it without enabling it into the core. YMMV, some folks like to just Christmas Tree light it all up at once and see what happens (write the finished code first then debug a bunch of code not knowing where to start looking).