This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Add OSE operating system support [3/5] remote relocation support


This is introduce of remote relocation support from Pedro:
The current qOffsets packet isn't good enough for OSE, for a few
reasons.  OSE elf binaries have an extra segment, in addition to
the usual code and data segments.  This segment contains something
like "load module configuration data", which is just a string of
configurations pertinent to the OSE loader.

Program Headers:
   Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
   LOAD           0x000718 0x0102ef8c 0x0102ef8c 0x00800 0x00800 R   0x4
   DYNAMIC        0x000f18 0x00000000 0x00000000 0x04500 0x00000 R   0x4
   LOAD           0x005418 0x01000000 0x01000000 0x2ef8c 0x2ef8c R E 0x10000
   LOAD           0x0343a4 0x01030000 0x01030000 0x00080 0x0082c RW  0x20

  Section to Segment mapping:
   Segment Sections...
    00     LMCONF
    01
    02     .text .rodata .eh_frame
    03     .data .sbss .bss


Sections: Idx Name Size VMA LMA File off Algn 0 .text 00028c38 01000000 01000000 00005418 2**5 CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE 1 .ctors 00000000 01028c38 01028c38 00034424 2**0 CONTENTS 2 .dtors 00000000 01028c38 01028c38 00034424 2**0 CONTENTS 3 .rodata 00006304 01028c38 01028c38 0002e050 2**3 CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA 4 .eh_frame 00000050 0102ef3c 0102ef3c 00034354 2**2 CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA 5 .sdata2 00000000 0102ef8c 01030080 00034424 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 6 .data 00000080 01030000 01030000 000343a4 2**2 CONTENTS, ALLOC, LOAD, RELOC, DATA 7 .sdata 00000000 01030080 01030080 00034424 2**2 CONTENTS, ALLOC, LOAD, DATA 8 .sbss 0000000c 01030080 01030080 00034424 2**2 ALLOC 9 .bss 0000078c 010300a0 010300a0 00034424 2**5 ALLOC <snip dwarf sections> ... 18 LMCONF 00000800 0102ef8c 0102ef8c 00000718 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 19 .comment 00000828 00000000 00000000 0004f056 2**0 CONTENTS, READONLY 20 .debug_ranges 00000018 00000000 00000000 0004f87e 2**0 CONTENTS, READONLY, DEBUGGING

The OSE debug API only gives us section load addresses,
not offsets, which is what qOffsets wants, when given sections
instead of segments.  OSE executables are fully linked binaries,
not relocatable objects, otherwise, offsets or absolute addresses
would be the same thing.  In any case, since there's an extra segment,
qOffsets wouldn't be able to relocate that extra segment correctly,
given only .text and .data offsets.

So, between extending qOffsets and coming up with something new,
I chose the latter.  I also thought of extending
qXfer:libraries:read to be able to report the main executable,
and extract the main executable's relocation info from that,
but I ended instead adding a new, but similar query.  I think
we could make it work, but it adds dependencies on which solib
backend is in use, and, it looks like it would complicate
the implementation quite a bit.


In a nutshell, the target reports either segment or section absolute load addresses, in the same order as the segments or allocated sections appear on the executable file. From the patch:

+@smallexample
+<load-map>
+  <segment address="0x10000000"/>
+</load-map>
+@end smallexample
+
+Another simple load map, for a program with three allocated sections
+(.text, .data, .bss), looks like this:
+
+@smallexample
+<load-map>
+  <section address="0x10000000"/>
+  <section address="0x20000000"/>
+  <section address="0x30000000"/>
+</load-map>
+@end smallexample


I thought of also adding support for reported section offsets instead of addresses, and optional section names (as an optional attribute), for the case of the debug API not giving us the sections in the same order as in is in binary. But since we need to keep supporting qOffsets forever anyway, I resisted adding that upfront until we find a need. I don't actually know of any target that would need that. We'd have seen a qOffsets extension/replacement sooner if there'd been a hard need before, I'd think.

The possibility of adding optional xml attributes to the
dtd in the future, was what made me add the
xml_find_attribute function used like so:

+  struct load_map_info *info = user_data;
+  ULONGEST *address_p = xml_find_attribute (attributes, "address")->value;
+  CORE_ADDR address = (CORE_ADDR) *address_p;

instead of relying on attribute position, like we do in
other places parsing xml.  E.g., solib-target.c:

   struct lm_info *last = VEC_last (lm_info_p, *list);
   ULONGEST *address_p = VEC_index (gdb_xml_value_s, attributes, 0)->value;
   CORE_ADDR address = (CORE_ADDR) *address_p;

Sound like unnecessary hardcoding that way.

Comments on all of this, before I pass it upstream?  Maybe
there's some use case we've wished before qOffsets would
handle?

I've confirmed that OSE binaries are relocated correctly
with a patch that implements this packet in the OSE stub.


(BTW, this new packet started out spelled as "qXfer:offsets:read", but it looked silly given that it doesn't support offsets as of yet... load-map was the best I came up with, after considering names like "qXfer:relocation-info:read". Anyway, whatever name, works for me.)

Thanks,
Hui

2013-03-08  Pedro Alves  <pedro@codesourcery.com>
	    Luis Machado  <lgustavo@codesourcery.com>

	* corelow.c (Makefile.in): Add load-map.dtd.
	* features/load-map.dtd: New.
	* remote.c (get_offsets): Removed.
	(PACKET_qXfer_load_map, load_map_start_segment,
	load_map_start_section, load_map_start, load_map_end,
	free_load_map, free_current_contents_load_map,
	segment_attributes, section_attributes, load_map_children,
	load_map_attributes, load_map_elements, parse_load_map,
	remote_relocate_using_qXfer_load_map,
	remote_relocate_using_qOffsets, remote_relocate): New.
	(remote_start_remote): Call remote_relocate.
	(remote_pr): Add qXfer:load-map:read.
	(extended_remote_attach_1): Call remote_relocate.
	(remote_xfer_partial): Handle TARGET_OBJECT_LOAD_MAP.
	(_initialize_remote): Add load-map command.

On 03/05/13 18:01, Hui Zhu wrote:
Hi,

This patch add relocation support to remote target.
If target support qXfer:load-map:read, it use this packet to request a list of segment or section load addresses of the main executable.
If target doesn't support it, use qOffsets that support in before request section offsets.

Thanks,
Hui

2013-03-05 Luis Machado <lgustavo@codesourcery.com>

     * corelow.c (Makefile.in): Add load-map.dtd.
     * features/load-map.dtd: New.
     * remote.c (get_offsets): Removed.
     (PACKET_qXfer_load_map, load_map_start_segment,
     load_map_start_section, load_map_start, load_map_end,
     free_load_map, free_current_contents_load_map,
     segment_attributes, section_attributes, load_map_children,
     load_map_attributes, load_map_elements, parse_load_map,
     remote_relocate_using_qXfer_load_map,
     remote_relocate_using_qOffsets, remote_relocate): New.
     (remote_start_remote): Call remote_relocate.
     (remote_pr): Add qXfer:load-map:read.
     (extended_remote_attach_1): Call remote_relocate.
     (remote_xfer_partial): Handle TARGET_OBJECT_LOAD_MAP.
     (_initialize_remote): Add load-map command.


Attachment: ose_load_map_remote.txt
Description: Text document


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]