Version: 5.0 Platform: i586-pc-sco3.2v5.0.2 Compiler: gcc-2.95.2 Linker works so that *some* data items from shared object .data section are located in main executable's `.bss' section. All code works with this address, not with address in shared object's `.data' section. By some OS `magic' those data items get filled correctly when process starts. This was the case for keymap arrays (which size is 2048 bytes) in `libreadline.so.4', including vi_movement_keymap, and `bash' executable. I did not observe this with other users of the same `libreadline.so.4'. Those data items are noted in main executable's symbol table and when gdb works with this executable without creating a subprocess, `print &vi_movement_keymap' yields correct address (in main executable's `.bss'). But when subprocess is running and shared objects are loaded, the same gdb command will print address in shared object's `.data' (as tuned by dynamic linking). So user has trouble looking at data which are really accessed (and perhaps modified) by code. Standard `print' commands will show initial value of data item, not current one.
