From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kevin Buettner To: Daniel Jacobowitz , Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: [rfa] gdbserver 2/n - signals Date: Thu, 19 Jul 2001 17:22:00 -0000 Message-id: <1010720002145.ZM6047@ocotillo.lan> References: <20010719120143.A19963@nevyn.them.org> <3B574A5D.6030403@cygnus.com> <20010719141742.A25968@nevyn.them.org> X-SW-Source: 2001-07/msg00501.html On Jul 19, 2:17pm, Daniel Jacobowitz wrote: > > o > > I don't understand the need for the file > > gdbserver/signals.c. Isn't that what > > gdb/signals.c is for? > > I was going to use that, except for a few small problems: > - wasted space, a couple of functions and the large name table. > I'm not really bothered by this one. > - warning() and internal_error() calls, which gdbserver doesn't > provide. > > Perhaps re-using it despite those minor hurdles would be wiser. I'll > tweak the patch. I'm not convinced that it's a good idea to share code between gdb and gdbserver. The problem with sharing code is that it's really easy to break gdbserver if you're not careful. I think it might be better to revamp gdbserver so that it shares no code in common with gdb. The other alternative is to go to the other extreme and attempt to do maximal sharing. But I think this will be harder to do and I suspect the end result will be much less useful than some people think. I used gdbserver a while back to do the initial development of the IA-64 port. I really liked it that gdbserver was small and required very little work to bring up on a new machine. I think we should continue to strive to keep gdbserver as small as possible. Kevin