The bflt loader in the kernel will, however, add a small extra data table
just before .data's content (cf. handling of MAX_SHARED_LIBS in
binfmt_flat.c:load_flat_file).
Now, if .text and .data are in the same segment, directly following each
other in the binary file, but have that extra data table added in the
run-time memory layout, GDB will get very confused when trying to access
items in the now-moved .data section. Without any kernel (loader) / GDB
changes, the solution is to tell the linker to always put .text and .data
into separate segments, which GDB will handle gracefully then.