This is the mail archive of the gdb-prs@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: corefiles/1905: Is SPARC 64 bit supported?


The following reply was made to PR corefiles/1905; it has been noted by GNATS.

From: "Pickett, David" <David.Pickett@phlx.com>
To: 'Daniel Jacobowitz' <drow@false.org>
Cc: gdb-gnats@sources.redhat.com
Subject: RE: corefiles/1905: Is SPARC 64 bit supported?
Date: Thu, 7 Apr 2005 18:17:31 -0400 

 Looking in the oldest files first for CFLAGS generating code, I do see the
 sort of stuff I am talking about in ltcf-cxx.sh, and from the content, I
 suppose that is a GNU standard file.  I was surprised that the latest gcc
 and the latest gdb downloads have different ltcf-cxx.sh files (with no
 different sccs ids or dates or versions in them)!  They build some of the
 same lib dirs, too, for some reason.
 
 tdas-srv2:2:pts/138 /export/home/uabdp3
 $ find l/* -name ltcf-cxx.sh -ls                    
 65562   40 -rw-r--r--   1 uabdp3   tdasdev     39078 Nov 19  2003
 l/gcc-3.4.3/ltcf-cxx.sh
 60119   40 -rw-r--r--   1 uabdp3   tdasdev     37118 Oct  5  2004
 l/gdb-6.3/ltcf-cxx.sh
 tdas-srv2:2:pts/138 /export/home/uabdp3
 $ 
 
 
 Not being a GNU developer yet, I was unsure of the exact nature of the
 division between GNU and GDB.  I don't know if they have addressed the 32/64
 dichotomy, both in terms of recognizing 64 bit capabilities, and allowing
 them to be both displayed and chosen.
 
 Still, I think that if 64/32 bit capability is available, it should the
 default.  I can't see it being a problem that it works more often, and it is
 not often that 64 bit speed or size impacts are meaningful for a tool like
 gdb!  Are you hinting that 32 is the better default because the 64 bit gdb
 cannot handle 32 bit compiled objects?  And think of the reduction in emails
 when there is no problem!
 
 
 Well, after a lot of hacking -m64 into all potential CFLAGS sources,
 success!:
 
 tdas-srv2:1:pts/160 /export/home/uabdp3
 $ sol
 Segmentation Fault(coredump)
 tdas-srv2:1:pts/160 /export/home/uabdp3
 $ gdb bin/sol core  
 GNU gdb 6.3
 Copyright 2004 Free Software Foundation, Inc.
 GDB is free software, covered by the GNU General Public License, and you are
 welcome to change it and/or distribute copies of it under certain
 conditions.
 Type "show copying" to see the conditions.
 There is absolutely no warranty for GDB.  Type "show warranty" for details.
 This GDB was configured as "sparc64-sun-solaris2.8"...
 (no debugging symbols found)
 
 Core was generated by `sol'.
 Program terminated with signal 11, Segmentation fault.
 Reading symbols from /usr/lib/sparcv9/libc.so.1...(no debugging symbols
 found)...done.
 Loaded symbols for /usr/lib/64/libc.so.1
 Reading symbols from /usr/lib/sparcv9/libdl.so.1...(no debugging symbols
 found)...done.
 Loaded symbols for /usr/lib/64/libdl.so.1
 Reading symbols from
 /usr/platform/SUNW,Ultra-Enterprise/lib/sparcv9/libc_psr.so.1...
 (no debugging symbols found)...done.
 Loaded symbols for
 /usr/platform/SUNW,Ultra-Enterprise/lib/sparcv9/libc_psr.so.1
 #0  0xffffffff7f23c07c in strlen ()
    from /usr/lib/64/libc.so.1
 (gdb) where
 #0  0xffffffff7f23c07c in strlen () from /usr/lib/64/libc.so.1
 #1  0xffffffff7f28f274 in _doprnt () from /usr/lib/64/libc.so.1
 #2  0xffffffff7f290eb0 in printf () from /usr/lib/64/libc.so.1
 #3  0x0000000100000860 in main ()
 (gdb) quit
 tdas-srv2:1:pts/160 /export/home/uabdp3
 $ 
 
 
 
 Thanks,
 
 David Pickett
 
 PS: One of the odd purposes I often use gdb for is: I make a periodic cron
 job that runs a script scouring the production server looking for core
 files, runs file on them, tries to find the executable in a probable PATH,
 runs gdb where on them, and emails me a report of what is breaking.
 Otherwise, one often does not hear!  Known bugs can be identified and
 ignored, and new bugs detected.  Ignorance is bliss, knowledge is power, and
 you get to choose!
 
 I think I immediately moved them to a holding space so they would not be
 overwritten before I analyzed them.  After all, they are all called core, so
 if you don't set them aside, an interesting one might be overwritten before
 you see it.  Also, the usual core file permissions means one user's core
 file blocks all future core dumps in a shared dir like /tmp.  After the gdb
 email, I moved them to a date-time name for future reference and did a 'nice
 -19 gzip -9' to cut space needed.  I forget how I managed space, probably
 automatically tossing dumps after 10 days.
 
 Gdb was particularly nice to have, as our dbx license was tied to the
 development box, when I even had dbx!
 
 The wonderful Solaris tool 'truss', and good coding practices, have saved me
 from actually debugging code most decades!  Truss can, for instance, take a
 short snapshot of system calls on a running piece of software with no
 preparation, source code, break points, and with the app running at a fair
 clip, if somewhat reduced in speed just until the truss ends!  AIX has
 truss, too, apparently a bit weaker flavor, so I guess it is flowing towards
 being a standard.  I assume it uses a hook in the kernel so a 'truss
 process' can have the kernel intercept all 'target process' calls and show
 them to the 'truss process' before returning on the target call.
 
 -----Original Message-----
 From: 'Daniel Jacobowitz' [mailto:drow@false.org]
 Sent: Thursday, April 07, 2005 3:15 PM
 To: Pickett, David
 Cc: gdb-gnats@sources.redhat.com
 Subject: Re: corefiles/1905: Is SPARC 64 bit supported?
 
 
 On Thu, Apr 07, 2005 at 03:09:43PM -0400, Pickett, David wrote:
 > No, despite the *64* configure, it seems to be 32 bit:
 > 
 > tdas-srv2:1:pts/160 /export/home/uabdp3/l/gdb-6.3
 > $ file $(whence gdb)
 > /export/home/uabdp3/l/local/bin/gdb:    ELF 32-bit MSB executable SPARC
 > Version 1, dynamically linked, not stripped
 > tdas-srv2:1:pts/160 /export/home/uabdp3/l/gdb-6.3
 > $ 
 > 
 > 
 > I had the 64 bit capable gcc latest 3.4.3 in my path, but it failed to use
 > the -m64 to make 64 bit executables, like here:
 > 
 > gcc -c -g -O2     -I. -I. -I./config
 > -DLOCALEDIR="\"/export/home/uabdp3/l/local/share/locale\"" -DHAVE_CONFIG_H
 > -I./../include/opcode -I./../readline/.. -I../bfd -I./../bfd
 -I./../include
 > -I../intl -I./../intl  -DMI_OUT=1 -DTUI=1 -Wimplicit -Wreturn-type
 -Wcomment
 > -Wtrigraphs -Wformat -Wparentheses -Wpointer-arith -Wuninitialized
 > -Wformat-nonliteral -Wunused-label -Wunused-function  sparc64-sol2-tdep.c
 
 You have to take care of that yourself - standard practice for using a
 compiler which defaults to 32-bit.  Try setting CFLAGS first.
 
 > BTW, it seems like it should be able to parse 64 bit core files with 32
 bit
 > code, if it knows the layout.  There's nothing going on over 2G in size!
 
 It's possible that the problem is something completely different.  But
 a 64-bit GDB is the first thing to try before looking for more subtle
 problems.  I believe the Solaris debugger gets the layout of core files
 from a Solaris header; that header provides only 32-bit interfaces to a
 32-bit GDB.
 
 
 -- 
 Daniel Jacobowitz
 CodeSourcery, LLC


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