Here is a patch to fix a ``misunderstanding'' between the kernel (bflt

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  <[email protected]>

elf2flt.ld.in

@@ -5,6 +5,11 @@ MEMORY {
 	flatmem : ORIGIN = 0x0, LENGTH = 0xfffffff
 }
 
+PHDRS {
+	text PT_LOAD ;
+	data PT_LOAD ;
+}
+
 SECTIONS {
 
 	.text 0x0 : {
@@ -38,7 +43,7 @@ W_RODAT		*(.gnu.linkonce.r*)
 
 		. = ALIGN(0x20) ;
 		@SYMBOL_PREFIX@_etext = . ;
-	} > flatmem
+	} > flatmem :text
 
 	.data : {
 		. = ALIGN(0x4) ;
@@ -130,7 +135,7 @@ TOR:		@SYMBOL_PREFIX@__DTOR_END__ = .;
 		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