From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9885 invoked by alias); 15 Jul 2003 14:49:32 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 9870 invoked from network); 15 Jul 2003 14:49:31 -0000 Received: from unknown (HELO cerbere.u-strasbg.fr) (130.79.112.250) by sources.redhat.com with SMTP; 15 Jul 2003 14:49:31 -0000 Received: from laocoon.ics.u-strasbg.fr (laocoon.u-strasbg.fr [130.79.112.72]) by cerbere.u-strasbg.fr (Postfix) with ESMTP id 03F9A2C26A9; Tue, 15 Jul 2003 16:56:07 +0200 (CEST) Message-Id: <5.0.2.1.2.20030715162155.04307e60@ics.u-strasbg.fr> X-Sender: muller@ics.u-strasbg.fr Date: Tue, 15 Jul 2003 14:49:00 -0000 To: gdb@sources.redhat.com;, gdb-patches@sources.redhat.com From: Pierre Muller Subject: 6.0 BUG? SIGSEGV under cygwin Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-SW-Source: 2003-07/txt/msg00161.txt.bz2 I compiled the 6.0 branch GDB with -gstabs+ debug option. I think that there is a problem in the current main and 6.0 branches, regarding use of sym_private file of struct objfile. This field is used to stored two incompatible things : in dwarf2-frame.c it is assumed that this field contains a struct dwarf2_fde pointer, but the same field is also used in coffread.c and xcoffread.c to store a struct coff_symfile_info pointer. These two structures are completely incompatible and lead to the crash with the following backtrace : (gdb) bt 6 #0 dwarf2_frame_find_fde (pc=0x10ad7068) at ../../src/gdb/dwarf2-frame.c:1038 #1 0x005542e2 in dwarf2_frame_cache (next_frame=0x10121ba0, this_cache=0x10121c0c) at ../../src/gdb/dwarf2-frame.c:505 #2 0x0055469e in dwarf2_frame_this_id (next_frame=0x10121ba0, this_cache=0x10121c0c, this_id=0x10121c28) at ../../src/gdb/dwarf2-frame.c:600 #3 0x0046d980 in get_frame_id (fi=0x10121bf8) at ../../src/gdb/frame.c:243 #4 0x004706fa in get_prev_frame (this_frame=0x10121bf8) at ../../src/gdb/frame.c:1924 #5 0x0042963c in backtrace_command_1 (count_exp=0x0, show_locals=0, from_tty=1) at ../../src/gdb/stack.c:1215 (More stack frames follow...) the source listing looks like this : (gdb) li -20 1018 inital location associated with it into *PC. */ 1019 1020 static struct dwarf2_fde * 1021 dwarf2_frame_find_fde (CORE_ADDR *pc) 1022 { 1023 struct objfile *objfile; 1024 1025 ALL_OBJFILES (objfile) 1026 { 1027 struct dwarf2_fde *fde; (gdb) 1028 CORE_ADDR offset; 1029 1030 offset = ANOFFSET (objfile->section_offsets, SECT_OFF_TEXT (objfile)); 1031 1032 fde = objfile->sym_private; 1033 while (fde) 1034 { 1035 if (*pc >= fde->initial_location + offset 1036 && *pc < fde->initial_location + offset + fde->address_range) (gdb) p objfile.name $30 = 0x10a44430 "/cygdrive/f/pas/cvs100/bin/CYGWIN1.DLL" p *fde makes no sense, but p *(struct coff_symfile_info *)fde does make sense: (gdb) p *fde $28 = {cie = 0x0, initial_location = 0, address_range = 1627394048, instructions = 0xc9018
, end = 0x0, next = 0x0} (gdb) p /x *(struct coff_symfile_info *)fde $29 = {min_lineno_offset = 0x0, max_lineno_offset = 0x0, textaddr = 0x61001000, textsize = 0xc9018, stabsects = 0x0, stabstrsect = 0x0, stabstrdata = 0x0} Which looks rather reasonable to people who know cygwin a little : 0x61000000 is the default base address of the cygwin DLL. I have really no idea how to fix the problem, but I hope that my message is clear enough. The following steps should be enough to reproduce the problem, on a cygwin system only, of course. ::::1) recompile the gdb with -gstabs+ debug option. ::::2) run the created gdb on itself. ./gdb ./gdb in build/gdb dir. ::::::3) set a breakpoint in command_loop (top-gdb) b command_loop ::::::4) run the inferior (top-gdb) run (top-gdb) run Starting program: /home/muller/gdb/gdb60/build/gdb/gdb.exe warning: obsolete '/home/muller/gdb.ini' found. Rename to '/home/muller/.gdbinit '. GNU gdb 5.3.90_2003-07-15-cvs adapted to Free Pascal Copyright 2003 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 "i686-pc-cygwin". Breakpoint 3, command_loop () at ../../src/gdb/top.c:760 760 int stdin_is_tty = ISATTY (stdin); ::::::5) ask for a backtrace (top-gdb) bt #0 command_loop () at ../../src/gdb/top.c:760 Segmentation fault (core dumped) I used an older gdb to be able to find out the problem..... I hope this will be fixed before 6.0 release.... Pierre Muller Institut Charles Sadron 6,rue Boussingault F 67083 STRASBOURG CEDEX (France) mailto:muller@ics.u-strasbg.fr Phone : (33)-3-88-41-40-07 Fax : (33)-3-88-41-40-99