bt: order of .text symbols in debuginfo important?

[Jim Keniston <jkenisto at linux dot vnet dot ibm dot com>]

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>, 
    cache=<value optimized out>, data=<value optimized out>, 
    channel=<value optimized out>) at /usr/include/bits/string3.h:52
#2  unix_write_blk64 (block=<value optimized out>, 
    cache=<value optimized out>, data=<value optimized out>, 
    channel=<value optimized out>) at unix_io.c:690
#3  0x000000000041a6c1 in ?? ()
#4  0x00007fff430432c0 in ?? ()
#5  0x000000007f2bb724 in ?? ()
#6  0x0000000000000000 in ?? ()
(gdb)

For comparison, when I point a fresh gdb instance at fsck.ext2 (no core
file), I'm able to set a breakpoint at e2fsck_handle_read_error.

Thanks for any suggestions.  I'd appreciate being cc-ed on responses,
since I'm not subscribed to this list; but I'll monitor the archive for
a while just in case.

Jim Keniston
IBM Linux Technology Center