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] |
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:
signature.asc
Description: This is a digitally signed message part.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |