bt: order of .text symbols in debuginfo important?

For purposes of associating functions with .text addresses when creating
a backtrace, does gdb assume that the .text symbols for static functions
in a particular source file are in ascending order by address in the
debuginfo file?  That seems to be the case ALMOST universally in the
debuginfo file I'm looking at, but there's one source file (ehandler.c)
with just 2 static functions, and they're in reverse order in the
debuginfo:

$ objdump -t fsck.ext2.debug
...
0000000000000000 l    df *ABS*  0000000000000000 ehandler.c
000000000062d340 l     O .bss   0000000000000008 operation
000000000041a540 l     F .text  00000000000001bc e2fsck_handle_read_error
000000000041a3d0 l     F .text  000000000000016f e2fsck_handle_write_error
0000000000000000 l    df *ABS*  0000000000000000 problem.c
000000000062cd40 l     O .data  00000000000000b0 pr_latch_info
000000000041a7d0 l     F .text  000000000000005d reconfigure_bool
...

This is of interest to me because gdb's bt of a core file goes bad when
it hits e2fsck_handle_read_error's frame:

...
Loaded symbols for /lib64/ld-linux-x86-64.so.2
Core was generated by `fsck.ext2 -f -y /dev/buse0'.
Program terminated with signal 11, Segmentation fault.
#0  0x00007f1618b0db8b in memcpy () from /lib64/libc.so.6
(gdb) where
#0  0x00007f1618b0db8b in memcpy () from /lib64/libc.so.6
#1  0x00007f1619633473 in reuse_cache (block=<value optimized out>,