Debugging signal handlers from core file with GDB

I'm debugging a core file where I received a segment violation. According to the core file, this occurs when the program attempts to access a valid section of memory. We have a log that shows there was a call to madvise(addr,size,MADV_DONTNEED) earlier, where this address was in the given range. This means it was likely swapped out at the time of the call.

Furthermore, when debugging the core file, if we do a dump of the $_siginfo structure, it shows that si_signo = 11, and si_addr = 1234, where 1234 is the pid of the process. Currently, we're suspecting that we got a SIGBUS, and someone registered a handler that is raising a SEGV.

So, two questions: -- first is it possible in GDB to view the stack of the signal handler? I was under the impression that the signal handler would use the processes stack, but a raw dump of the stack space does not show any evidence that this is the case (I suspect someone explicitly registered a signal handler stack in this case),

And second, is there a way in GDB to tell from the core file what signal handler is registered to a particular signal? info signal doesn't tell me this.

----- EDIT ----------

some more details: This is on an arm32 bit userspace application. GDB shows:

(gdb) list
234     port_get_port_info (handle_t handle)
235     {
236         port_info_t *port_info;
237         int rc;
238
239         rc = id_to_ctx(port_db, handle, (void **)&port_info);

(where 239 is the line of failure -- note that port_db is a global on a page that was madvised to be swapped out, so we're expecting a SIGBUS here)

(gdb) info inferior
  Num  Description       Executable
* 1    process 9820      /home/dev/ws1/fuzzy_bunny

(gdb) p $_siginfo
$1 = {
  si_signo = 11,
  si_errno = 0,
  si_code = 0,
  _sifields = {
    _pad = {9820, 0 <repeats 28 times>},
    ...
    _sigchld = {
      si_pid = 9820,
      si_uid = 0,
      si_status = 0,
      si_utime = 0,
      si_stime = 0
    },
    _sigfault = {
      si_addr = 0x265c
    },
  }
}

And:

(gdb) bt 1
#0  0xf76e041c in port_get_port_info (handle=4278190136) at /home/dev/ws1/code/fuzzy_bunny/src/port_api.c:239
(More stack frames follow...)

So backtrace does not show the signal handler, which is what I would need to see at the moment.

(gdb) info registers
r0             0x22a564 2270564
r1             0xff000038       4278190136
r2             0xee007574       3993007476
r3             0x0      0
r4             0x0      0
r5             0xee007758       3993007960
r6             0xff000038       4278190136
r7             0x6      6
r8             0xee007760       3993007968
r9             0xee007758       3993007960
r10            0xee007608       3993007624
r11            0x2364418        37110808
r12            0xf78da92c       4153256236
sp             0xee007568       0xee007568
lr             0xf76dc37c       -143801476
pc             0xf76e041c       0xf76e041c <port_get_sb+60>
cpsr           0x8f0010 9371664
fpscr          0x80000010       -2147483632

and the asm:

   x0xf76e0414 <port_get_sb+52>         ldr    r0, [pc, #196]  ; 0xf76e04e0 <port_get_sb+256>                                                       x
   x0xf76e0418 <port_get_sb+56>         add    r2, sp, #12                                                                                              x
b+>x0xf76e041c <port_get_sb+60>         ldr    r0, [pc, r0]                                                                                             x
   x0xf76e0420 <port_get_sb+64>         bl     0xf76cc8b4 <id_to_ctx@plt>                                                                       x

Again, what I'm looking for is a way to see what's happening in the signal handler from GDB...