This is the mail archive of the gdb-patches@sources.redhat.com 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: [rfa] gdbserver signal handling


> Er, why did you create src/gdb/signals.c?
> 
> 
> The reason to create src/gdb/signals.c has nothing to do with
> gdbserver; it has to do with:
>   - the cleanup I never got to of removing <signal.h> from target.c,
>   since <signal.h> is a host header but used for target information.
> 
>   - the eventual moving of signals.c to be in NATDEPFILES.
> 
> I don't want to move it to gdbserver, because I've finally reached no
> code sharing.  And because of something you said once, which is now
> true:
> 
>> I think, in terms of better splitting up gdbserver and gdb it is pretty
>> much a requirement.  I can but dream of the day when GDBSERVER stops
>> including defs.h :-)
> 
> 
> 
> That's why I wanted to do it the above way.

I suspect there is a difference between not including defs.h and 
unnecessarily duplicating common code.  My memory was that the signal 
enums were to be moved to their own header file (so things like 
gdbserver could include them).

This gdb/gdbserver/signals.c looks largely like a copy of big chunks of 
gdb/signals.c and other similar code.  I don't know that gdb developers 
want to take on responsability for maintaining such duplication.

Again, I think this can be cleaned up properly, but after the 5.2 branch 
goes through.

enjoy,
Andrew



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