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

Mike Frysinger
2013-05-15T17:12:47Z

[-- Attachment #1: Type: Text/Plain, Size: 1501 bytes --]

On Wednesday 15 May 2013 12:26:06 Luis Machado wrote:
> On 05/15/2013 06:06 PM, Mike Frysinger wrote:
> > On Wednesday 15 May 2013 07:25:34 Luis Machado wrote:
> >> 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.
> >
> > well, not to be pedantic, but this is for FLAT programs, not uClibc
>
> Ok. uClibc has been used here due to its gdbserver-specific #if guard
> explicitly checking for UCLIBC and mmu-lessness.

because no other C lib supports FLAT currently :)

> >> 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.
> >
> > you mean FDPIC ? gdb already supports that and uses a different set of
> > ptrace requests for that. ideally, gdb nor gdbserver should not be tied
> > to a specific file format (what format it happened to be compiled for).
> > instead, gdbserver should support all formats and then gdb detects the
> > format and changes its requests based on that.
>
> Not FDPIC, but DSBT. I agree gdb/gdbserver should be format-agnostic,
> but it grew like this. Let's not extend the uglyness though.

i thought someone already committed support for DSBT, and i helped merge some
of the FDPIC differences. it was for the c6x port iirc.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]