[RFC, gdbserver] Avoid defining linux_read_offsets when the target does not need it

[Luis Machado]

Hi,

uClibc-based targets can load their programs in an offset in memory, and 
this information has historically been communicated to gdbserver via 
ptrace with the following options: PT_TEXT_ADDR, PT_DATA_ADDR and 
PT_TEXT_END_ADDR.

We have a target that uses loadmaps as opposed to the above mechanism. 
It is just another ptrace request, but it doesn't use linux_read_offsets 
at all.

linux_read_offsets is always defined (for uClibc-based targets) though, 
so gdbserver eventually calls it and it obviously returns an error. This 
error is propagated all the way to GDB, displaying an alarming and 
cryptic warning on the host's side.

"warning: Remote failure reply: E01"

Though the warning is harmless, the handling of this scenario could be 
improved a little.

The following patch conditionally defines linux_read_offsets only for 
targets that are uClibc-based and that define PT_TEXT_ADDR, PT_DATA_ADDR 
and PT_TEXT_END_ADDR.

Targets using other mechanisms won't define this function then, making 
gdbserver return an empty response to GDB (meaning packet not 
supported). GDB is happy again.

Additionally, i see 3 different archs defining local constants. coldfire 
and c6x still seem to lack definitions in the kernel, but blackfin 
already has those.

I've asked Mike Frysinger whether these can be removed. If so, i'll 
update the patch.

Alternativelly, we could forward the burden of fetching offsets to the 
target backends, though the number of targets that would use this is 
quite limited.

Luis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-qoffsets_uclinux.diff
Type: text/x-patch
Size: 3672 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/gdb-patches/attachments/20130515/ec7e7107/attachment.bin>