This is the mail archive of the gdb-patches@sourceware.cygnus.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]

Re: AIX 4.3.2 new library and coredump format



   From: Johanna Svenningsson <mea@nada.kth.se>
   Date: 27 Mar 1999 06:14:58 +0200

   In AIX 4.3 the format of libraries and coredumps has been changed.
   I've tried to adapt gdb to both the new and old style. It might not be
   very beautiful, but it seems to be working for me at least. I've
   tested it on AIX 4.3.2 and 4.2.1.

Since these are all BFD changes, I've taken the liberty of forwarding
them to binutils@sourceware.cygnus.com for approval.

Upon looking through these, I note a few things that the binutils
maintainers will probably want you to do:

	   Attempted to make gdb understand the new format of AIX
	   coredumps and libraries.
	   * rs6000-core.c:	added code for new coredumpformat
	   * coff-rs6000.c:	handles new library format
	   * configure.in:		checks for core_dumpx-struct

The ChangeLog entry should have a little more detail about what's been
changed.  ChangeLog entries are indispensable to tracking down bugs
and understanding how the code is changing over time.

   ! #define	core_hdrs(bfd)		(((Rs6kCorData*)(bfd->tdata.any))->U_hdr.hdr)
   ! #ifdef HAVE_CORE_DUMPX
   ! #define	core_hdrx(bfd)		(((Rs6kCorData*)(bfd->tdata.any))->U_hdr.hdrx)
   ! #endif

Additions like this deserve at least a line of explanation that this has
to do with AIX 4.3.

   ! #ifdef HAVE_CORE_DUMPX
   !        if(coredata.c_entries == 0)
   !        {
   ! 	    is_big=true;

It seems petty I know, but you should try to follow the GNU coding standards,
so that it's easier for other people to read.  Copies of the standards are
online at gnu.org, and the texinfo file is in the GDB sources, under
etc/standards.texi.

Looking through the code under the is_big conditionals, I wonder it it
might not be better to define a whole new BFD for 64-bit corefiles.  I
didn't count accurately, but it looks like over 50% of the file might be
changed, which suggests that your new 64-bit code is not getting much
help from the existing code.

     #endif /* AIX_CORE */
   + 
   + 
   + 
   + 
   + 

Another small thing, let's not proliferate blank lines at the ends of
files.

   *** 594,600 ****

     /* XCOFF archives use this as a magic string.  */

   ! #define XCOFFARMAG "<aiaff>\012"
     #define SXCOFFARMAG 8

     /* This terminates an XCOFF archive member name.  */
   --- 594,601 ----

     /* XCOFF archives use this as a magic string.  */

   ! #define XCOFFBIGARMAG "<bigaf>\012"
   ! #define XCOFFSMALLARMAG "<aiaff>\012"

BFDers will rule on this, but if it were my choice, I would have
preferred to leave XCOFFARMAG unchanged and just add XCOFFBIGARMAG.
By renaming both symbols, you cause more churn in the code but not
(IMHO) improved comprehensibility by much.  In fact, people who've
read the code in the past and are familiar with the old symbols will
have to go back and see what this new symbol XCOFFSMALLARMAG is all
about.

   ! struct xcoff_ar_file_hdr

   --- 605,611 ----

   ! struct xcoff_ar_small_file_hdr

Similarly.

   + AC_EGREP_HEADER(core_dumpx,sys/core.h,AC_DEFINE(HAVE_CORE_DUMPX, 1, [Define if you have a struct core_dumpx]))

This is cool BTW, autoconf is the right way to go.

Anyway, I hope all this is helpful!  I'll be on vacation for a couple weeks,
hopefully the BFD patches will be taken care of by the time I get back, and
we can move on to the GDB work proper.  Thanks again for working on this!

								Stan

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