From mboxrd@z Thu Jan 1 00:00:00 1970 From: Elena Zannoni To: Kevin Buettner Cc: Elena Zannoni , gdb-patches@sources.redhat.com Subject: Re: [PATCH] xcoffread.c: remove include of partial-stab.h Date: Mon, 01 Oct 2001 14:29:00 -0000 Message-id: <15288.57821.215096.623909@krustylu.cygnus.com> References: <15287.35303.583879.469917@krustylu.cygnus.com> <1011001210800.ZM19181@ocotillo.lan> X-SW-Source: 2001-10/msg00020.html Kevin Buettner writes: > On Sep 30, 5:08pm, Elena Zannoni wrote: > > > Turns out that xcoffread.c used only 2 of the many cases handled by > > the switch in partial-stab.h. In order to reuse the whole file, a lot > > of macros had to be defined to do nothing. > > > > I tested this patch on an aix4.3 system. > > > > I know this file has no official maintainer, but I'll wait a few days > > to check it in anyway. > > I've looked this patch over. I've verified that only two cases of > partial-stab.h were needed by xcoffread.c. Also, it appears to me > that you've correctly integrated the two necessary cases into > xcoffread.c. Thanks for looking this over. > > My only concern about this patch is with the duplication of the two > cases in xcoffread.c. These hunks of code are of substantial size and > it occurs to me that correct maintenance of this code may require > keeping the various copies in sync. I'm wondering if it'd be possible > to turn these hunks of code into functions. That way we might be able > to avoid duplicating (some of) this code in three different places. > Yes, that was the way I started thinking about this code too. But I realized that it is probably better to completely decouple these cases, so that a change to accomodate format A doesn't affect format B or C. I think this common base was the reason for the 'fear' of change in this code. By making these independent, it will become easier to clean the code up w/o having to worry about other platforms, that may be hard to test on (I had to dig around quite a bit to find an AIX machine). I think the code can be simplified more this way too, for instance we can get rid of the macro DBXREAD_ONLY, and a few others. > Kevin Elena