loader) and GDB; noticed on m68k / coldfire uClinux.
Lacking specific directives in the linker script, the linker *may* decide
to put .text and .data into the same segment:
Section to Segment mapping:
Segment Sections...
00 .text .data .eh_frame_hdr .eh_frame .bss
01 .eh_frame_hdr
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.
Section to Segment mapping:
Segment Sections...
00 .text
01 .data .eh_frame_hdr .eh_frame .bss
Tested on m68k-uclinux (where the problem occurred) and arm-uclinuxeabi
(no regressions).
2010-02-27 Thomas Schwinge <thomas@codesourcery.com>
flatmem : ORIGIN = 0x0, LENGTH = 0xfffffff
}
+PHDRS {
+ text PT_LOAD ;
+ data PT_LOAD ;
+}
+
SECTIONS {
.text 0x0 : {
. = ALIGN(0x20) ;
@SYMBOL_PREFIX@_etext = . ;
- } > flatmem
+ } > flatmem :text
.data : {
. = ALIGN(0x4) ;
KEEP (*(.fini_array))
KEEP (*(SORT(.fini_array.*)))
PROVIDE (@SYMBOL_PREFIX@__fini_array_end = .);
- } > flatmem
+ } > flatmem :data
.eh_frame_hdr : { *(.eh_frame_hdr) } > flatmem
.eh_frame : { KEEP(*(.eh_frame)) } > flatmem