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: [RFC, gdbserver] Avoid defining linux_read_offsets when the target does not need it


On Wednesday 15 May 2013 14:07:31 Luis Machado wrote:
> On 05/15/2013 07:12 PM, Mike Frysinger wrote:
> > 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:
> >>>> 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.
> 
> That is correct, but there are a few differences in the loadmap format
> between targets.  My idea is to clean that up and make it more generic
> without having to use #if blocks inside linux-low.c.

as long as the functionality isn't based on the format gdbserver itself is 
compiled as, sounds fine.  i believe we cleaned up all the DSBT logic so that 
it isn't fighting with FLAT (i know on Blackfin we have a single gdbserver that 
can support FLAT or FDPIC).

glancing at the code, we do fail slightly in that it's currently DSBT||FDPIC, 
but in practice that hasn't mattered as no one has implemented both formats 
for the same architecture.

personally, i'd be interested in why DSBT was conceived in the first place 
instead of using the existing FDPIC.  are the minor differences on purpose ?  
by accident ?  or why people are using a different format from either DSBT or 
FDPIC ...
-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]