* Re: gdb.texinfo broken?
[not found] ` <38D7C977.FA3@cygnus.com>
@ 2000-03-21 11:31 ` J.T. Conklin
2000-03-21 14:56 ` Andrew Cagney
2000-04-01 0:00 ` Dmitry Sivachenko
0 siblings, 2 replies; 3+ messages in thread
From: J.T. Conklin @ 2000-03-21 11:31 UTC (permalink / raw)
To: Michael Snyder; +Cc: Eli Zaretskii, gdb-patches
>>>>> "Michael" == Michael Snyder <msnyder@cygnus.com> writes:
Michael> %] msnyder<2>% make gdb.info
Michael> makeinfo -I
Michael> /cleaver/blade/msnyder/sourceware/src/gdb/doc/../../readline/doc -I
Michael> /cleaver/blade/msnyder/sourceware/src/gdb/doc -o ./gdb.info gdb.texinfo
Michael> Making info file `./gdb.info' from `gdb.texinfo'.
Michael> gdb.texinfo:113: No matching `@end ifnottex'.
Michael> gdb.texinfo:156: Unmatched `@end'.
It looks like the changes to the directory entry require the latest
makeinfo. I tried to use makeinfo from texinfo-3.2 and it failed,
makeinfo from texinfo-4.0 works.
--jtc
--
J.T. Conklin
RedBack Networks
From Peter.Schauer@regent.e-technik.tu-muenchen.de Tue Mar 21 12:02:00 2000
From: "Peter.Schauer" <Peter.Schauer@regent.e-technik.tu-muenchen.de>
To: gdb-patches@sourceware.cygnus.com
Cc: tromey@cygnus.com
Subject: RFA: minsyms.c: Fixes for serious demangled hash minsym lookup flaws.
Date: Tue, 21 Mar 2000 12:02:00 -0000
Message-id: <200003212002.VAA19812@reisser.regent.e-technik.tu-muenchen.de>
X-SW-Source: 2000-03/msg00430.html
Content-length: 6596
There are two serious problems with the new demangled hash minsym
lookup code, causing lookup of demangled names to fail.
Here is an example, using the overload executable from the testsuite:
pes@eno_709$ gdb testsuite/gdb.c++/overload
GNU gdb 20000204
Copyright 1998 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 "i386-pc-solaris2.6"...
(gdb) b marker1
Function "marker1" not defined.
There are two reasons:
1) When handling the demangled name in install_minimal_symbols, the
current code adds the non-demangled name to the msymbol_demangled_hash
table, using a non-demangled hash algorithm and the non-demangled hash_next
link of the msymbol.
As add_minsym_to_hash_table has little code in common with the demangled
version, I created a new add_minsym_to_demangled_hash_table function.
2) The intended two pass lookup loop did not work, if
objfile->msymbol_hash[hash] was NULL, it never switched to the demangled
lookup pass.
Here is patch for both problems:
2000-03-21 Peter Schauer <pes@regent.e-technik.tu-muenchen.de>
* minsyms.c (add_minsym_to_demangled_hash_table): New function
to enter demangled msymbols into the hash table.
(install_minimal_symbols): Use it, instead of
add_minsym_to_hash_table.
(lookup_minimal_symbol): Reorganize pass loop so that demangled
symbols are found even if objfile->msymbol_hash[hash] is NULL.
*** gdb/minsyms.c.orig Mon Mar 13 19:29:23 2000
--- gdb/minsyms.c Tue Mar 20 20:35:25 2000
***************
*** 123,129 ****
--- 123,143 ----
}
}
+ /* Add the minimal symbol SYM to an objfile's minsym demangled hash table,
+ TABLE. */
+ static void
+ add_minsym_to_demangled_hash_table (struct minimal_symbol *sym,
+ struct minimal_symbol **table)
+ {
+ if (sym->demangled_hash_next == NULL)
+ {
+ unsigned int hash = msymbol_hash_iw (SYMBOL_DEMANGLED_NAME (sym));
+ sym->demangled_hash_next = table[hash];
+ table[hash] = sym;
+ }
+ }
+
/* Look through all the current minimal symbol tables and find the
first minimal symbol that matches NAME. If OBJF is non-NULL, limit
the search to that objfile. If SFILE is non-NULL, limit the search
***************
*** 167,226 ****
{
/* Do two passes: the first over the ordinary hash table,
and the second over the demangled hash table. */
! int pass = 1;
! msymbol = objfile->msymbol_hash[hash];
!
! while (msymbol != NULL && found_symbol == NULL)
{
! if (SYMBOL_MATCHES_NAME (msymbol, name))
{
! switch (MSYMBOL_TYPE (msymbol))
{
! case mst_file_text:
! case mst_file_data:
! case mst_file_bss:
#ifdef SOFUN_ADDRESS_MAYBE_MISSING
! if (sfile == NULL || STREQ (msymbol->filename, sfile))
! found_file_symbol = msymbol;
#else
! /* We have neither the ability nor the need to
! deal with the SFILE parameter. If we find
! more than one symbol, just return the latest
! one (the user can't expect useful behavior in
! that case). */
! found_file_symbol = msymbol;
#endif
! break;
! case mst_solib_trampoline:
! /* If a trampoline symbol is found, we prefer to
! keep looking for the *real* symbol. If the
! actual symbol is not found, then we'll use the
! trampoline entry. */
! if (trampoline_symbol == NULL)
! trampoline_symbol = msymbol;
! break;
! case mst_unknown:
! default:
! found_symbol = msymbol;
! break;
}
- }
! /* Find the next symbol on the hash chain. At the end
! of the first pass, try the demangled hash list. */
! if (pass == 1)
! msymbol = msymbol->hash_next;
! else
! msymbol = msymbol->demangled_hash_next;
! if (msymbol == NULL)
! {
! ++pass;
! if (pass == 2)
! msymbol = objfile->msymbol_demangled_hash[dem_hash];
}
}
}
--- 181,240 ----
{
/* Do two passes: the first over the ordinary hash table,
and the second over the demangled hash table. */
! int pass;
! for (pass = 1; pass <= 2 && found_symbol == NULL; pass++)
{
! /* Select hash list according to pass. */
! if (pass == 1)
! msymbol = objfile->msymbol_hash[hash];
! else
! msymbol = objfile->msymbol_demangled_hash[dem_hash];
!
! while (msymbol != NULL && found_symbol == NULL)
{
! if (SYMBOL_MATCHES_NAME (msymbol, name))
{
! switch (MSYMBOL_TYPE (msymbol))
! {
! case mst_file_text:
! case mst_file_data:
! case mst_file_bss:
#ifdef SOFUN_ADDRESS_MAYBE_MISSING
! if (sfile == NULL || STREQ (msymbol->filename, sfile))
! found_file_symbol = msymbol;
#else
! /* We have neither the ability nor the need to
! deal with the SFILE parameter. If we find
! more than one symbol, just return the latest
! one (the user can't expect useful behavior in
! that case). */
! found_file_symbol = msymbol;
#endif
! break;
! case mst_solib_trampoline:
! /* If a trampoline symbol is found, we prefer to
! keep looking for the *real* symbol. If the
! actual symbol is not found, then we'll use the
! trampoline entry. */
! if (trampoline_symbol == NULL)
! trampoline_symbol = msymbol;
! break;
! case mst_unknown:
! default:
! found_symbol = msymbol;
! break;
! }
}
! /* Find the next symbol on the hash chain. */
! if (pass == 1)
! msymbol = msymbol->hash_next;
! else
! msymbol = msymbol->demangled_hash_next;
}
}
}
***************
*** 934,941 ****
{
SYMBOL_INIT_DEMANGLED_NAME (msymbols, &objfile->symbol_obstack);
if (SYMBOL_DEMANGLED_NAME (msymbols) != NULL)
! add_minsym_to_hash_table (msymbols,
! objfile->msymbol_demangled_hash);
}
}
}
--- 948,955 ----
{
SYMBOL_INIT_DEMANGLED_NAME (msymbols, &objfile->symbol_obstack);
if (SYMBOL_DEMANGLED_NAME (msymbols) != NULL)
! add_minsym_to_demangled_hash_table (msymbols,
! objfile->msymbol_demangled_hash);
}
}
}
--
Peter Schauer pes@regent.e-technik.tu-muenchen.de
From jtc@redback.com Tue Mar 21 12:21:00 2000
From: jtc@redback.com (J.T. Conklin)
To: gdb-patches@sourceware.cygnus.com
Subject: RFA: tm-nbsd.h: define IN_SOLIB_CALL_TRAMPOLINE
Date: Tue, 21 Mar 2000 12:21:00 -0000
Message-id: <5maejsgjl8.fsf@jtc.redbacknetworks.com>
X-SW-Source: 2000-03/msg00431.html
Content-length: 1001
I submit the enclosed patch for approval. This allows programs linked
with shared libraries to be debugged on a.out-based NetBSD targets.
2000-03-21 J.T. Conklin <jtc@redback.com>
* tm-nbsd.h (IN_SOLIB_CALL_TRAMPOLINE): Define if not
SVR4_SHARED_LIBS.
Index: tm-nbsd.h
===================================================================
RCS file: /cvs/src/src/gdb/config/tm-nbsd.h,v
retrieving revision 1.1.1.2
diff -c -3 -p -r1.1.1.2 tm-nbsd.h
*** tm-nbsd.h 1999/07/07 20:11:33 1.1.1.2
--- tm-nbsd.h 2000/03/21 20:17:52
***************
*** 18,20 ****
--- 18,29 ----
along with this program; if not, write to the Free Software
Foundation, Inc., 59 Temple Place - Suite 330,
Boston, MA 02111-1307, USA. */
+
+ #ifndef SVR4_SHARED_LIBS
+
+ /* Return non-zero if we are in a shared library trampoline code stub. */
+
+ #define IN_SOLIB_CALL_TRAMPOLINE(pc, name) \
+ (name && !strcmp(name, "_DYNAMIC"))
+
+ #endif /* !SVR4_SHARED_LIBS */
--
J.T. Conklin
RedBack Networks
From jtc@redback.com Tue Mar 21 12:37:00 2000
From: jtc@redback.com (J.T. Conklin)
To: gdb-patches@sourceware.cygnus.com
Subject: RFA: i386/tm-nsbd.h, i386/nm-nbsd.h
Date: Tue, 21 Mar 2000 12:37:00 -0000
Message-id: <5m66uggiur.fsf@jtc.redbacknetworks.com>
X-SW-Source: 2000-03/msg00432.html
Content-length: 1734
I submit the enclosed patch for approval. These changes enable
floating point register support on NetBSD/i386.
--jtc
2000-03-21 J.T. Conklin <jtc@redback.com>
* i386/tm-nbsd.h (NUM_REGS): Removed.
(HAVE_I387_REGS): Defined.
* i386/nm-nbsd.h (FLOAT_INFO): Removed.
Index: tm-nbsd.h
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/tm-nbsd.h,v
retrieving revision 1.1.1.2
diff -c -3 -p -r1.1.1.2 tm-nbsd.h
*** tm-nbsd.h 1999/07/07 20:13:21 1.1.1.2
--- tm-nbsd.h 2000/03/21 20:22:36
***************
*** 21,31 ****
#ifndef TM_NBSD_H
#define TM_NBSD_H
#include "i386/tm-i386bsd.h"
#include "tm-nbsd.h"
-
- #undef NUM_REGS
- #define NUM_REGS 16
#define JB_ELEMENT_SIZE sizeof(int) /* jmp_buf[_JBLEN] is array of ints */
#define JB_PC 0 /* Setjmp()'s return PC saved here */
--- 21,30 ----
#ifndef TM_NBSD_H
#define TM_NBSD_H
+ #define HAVE_I387_REGS
+
#include "i386/tm-i386bsd.h"
#include "tm-nbsd.h"
#define JB_ELEMENT_SIZE sizeof(int) /* jmp_buf[_JBLEN] is array of ints */
#define JB_PC 0 /* Setjmp()'s return PC saved here */
Index: nm-nbsd.h
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/nm-nbsd.h,v
retrieving revision 1.1.1.2
diff -c -3 -p -r1.1.1.2 nm-nbsd.h
*** nm-nbsd.h 1999/07/07 20:12:53 1.1.1.2
--- nm-nbsd.h 2000/03/21 20:22:36
***************
*** 24,31 ****
/* Get generic NetBSD native definitions. */
#include "nm-nbsd.h"
- /* #define FLOAT_INFO { i386_float_info(); } */
-
#define REGISTER_U_ADDR(addr, blockend, regno) \
(addr) = i386_register_u_addr ((blockend),(regno));
--- 24,29 ----
--
J.T. Conklin
RedBack Networks
From msnyder@cygnus.com Tue Mar 21 12:47:00 2000
From: Michael Snyder <msnyder@cygnus.com>
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: hjl@lucon.org, gdb@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: Problems with hardware watchpoint on ia32.
Date: Tue, 21 Mar 2000 12:47:00 -0000
Message-id: <38D7DEE7.47D8@cygnus.com>
References: <20000307132401.A20282@valinux.com> <200003081008.FAA16481@indy.delorie.com> <20000308084304.A3150@lucon.org> <200003091211.HAA19860@indy.delorie.com>
X-SW-Source: 2000-03/msg00434.html
Content-length: 2108
Eli Zaretskii wrote:
>
> Problem no.2: Read watchpoints break when they shouldn't.
Accepted and checked in. --michael
> Example (slightly modified test program posted by H.J. Lu):
>
> $ cat wp.c
> int a1;
> int a2;
> int a3;
> int a4;
> int a5;
> int a6;
>
> unsigned long long ulla1 = 0;
> double da2 = 0;
>
> int main (void)
> {
> a2 = 12;
> a3 = 13;
> a4 = 14;
> a5 = 15;
> a6 = 16;
> a1 = 11;
> a2 = a4;
>
> ulla1 = 0x00000000ffffffffLL;
> da2 = 12;
> ulla1 = 0xffffffff00000000LL;
>
> return 0;
> }
>
> $ gcc -g -o wp wp.c
> $ gdb wp
> (gdb) watch a5
> Hardware watchpoint 2: a5
> (gdb) rwatch a5
> Hardware read watchpoint 3: a5
> (gdb) run
> Starting program g:/gdbsnap/gdb-0222/gdb/wp
> Hardware watchpoint 2: a5
>
> Old value = 0
> New value = 15
> Hardware read watchpoint 3: a5
>
> Value = 15
> main () at wp.c: 16
> 16 a5 = 15;
> (gdb)
>
> Now, it might seem like a strange idea to put two watchpoints on the
> same variable, but it is a very useful feature when each watchpoint
> has a different condition.
>
> Here's the patch:
>
> 2000-03-08 Eli Zaretskii <eliz@is.elta.co.il>
>
> * breakpoint.c (bpstat_stop_status): Don't stop if a read
> watchpoint appears to break, but the watched value changed.
>
> --- gdb/breakpoint.c~2 Wed Mar 8 19:20:28 2000
> +++ gdb/breakpoint.c Wed Mar 8 20:02:20 2000
> @@ -2620,6 +2620,17 @@ bpstat_stop_status (pc, not_a_breakpoint
> /* Stop. */
> break;
> case WP_VALUE_CHANGED:
> + if (b->type == bp_read_watchpoint)
> + {
> + /* Don't stop: read watchpoints shouldn't fire if
> + the value has changed. This is for targets which
> + cannot set read-only watchpoints. */
> + bs->print_it = print_it_noop;
> + bs->stop = 0;
> + continue;
> + }
> + ++(b->hit_count);
> + break;
> case WP_VALUE_NOT_CHANGED:
> /* Stop. */
> ++(b->hit_count);
From jtc@redback.com Tue Mar 21 12:47:00 2000
From: jtc@redback.com (J.T. Conklin)
To: gdb-patches@sourceware.cygnus.com
Subject: RFA: i386/nbsd.mt, i386nbsd-nat.c
Date: Tue, 21 Mar 2000 12:47:00 -0000
Message-id: <5m1z54gif1.fsf@jtc.redbacknetworks.com>
X-SW-Source: 2000-03/msg00433.html
Content-length: 6708
I submit the enclosed patch for approval. This change splits out
NetBSD native support from the FreeBSD, BSDI, and 386BSD support. The
changes I submitted earlier today convert the NetBSD target to use the
generic floating point register support, which conflicts with i386b-nat.c
--jtc
2000-03-21 J.T. Conklin <jtc@redback.com>
* i386/nbsd.mh (NATDEPFILES): Changed i386b-nat.c to i386nbsd-nat.c.
* i386nbsd-nat.c: New file.
Index: nbsd.mh
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/nbsd.mh,v
retrieving revision 1.1.1.1
diff -c -3 -p -r1.1.1.1 nbsd.mh
*** nbsd.mh 1999/04/16 01:34:19 1.1.1.1
--- nbsd.mh 2000/03/21 20:39:08
***************
*** 1,5 ****
# Host: Intel 386 running NetBSD
XDEPFILES= ser-tcp.o
! NATDEPFILES= fork-child.o infptrace.o inftarg.o corelow.o i386b-nat.o
XM_FILE= xm-nbsd.h
NAT_FILE= nm-nbsd.h
--- 1,5 ----
# Host: Intel 386 running NetBSD
XDEPFILES= ser-tcp.o
! NATDEPFILES= fork-child.o infptrace.o inftarg.o corelow.o i386nbsd-nat.o
XM_FILE= xm-nbsd.h
NAT_FILE= nm-nbsd.h
/* Native-dependent code for NetBSD/i386, for GDB.
Copyright 1988, 1989, 1991, 1992, 1994, 1996, 2000
Free Software Foundation, Inc.
This file is part of GDB.
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 59 Temple Place - Suite 330,
Boston, MA 02111-1307, USA. */
#include "defs.h"
#include <sys/types.h>
#include <sys/ptrace.h>
#include <machine/reg.h>
#include <machine/frame.h>
#include "inferior.h"
#include "gdbcore.h" /* for registers_fetched() */
#define RF(dst, src) \
memcpy(®isters[REGISTER_BYTE(dst)], &src, sizeof(src))
#define RS(src, dst) \
memcpy(&dst, ®isters[REGISTER_BYTE(src)], sizeof(dst))
struct env387
{
unsigned short control;
unsigned short r0;
unsigned short status;
unsigned short r1;
unsigned short tag;
unsigned short r2;
unsigned long eip;
unsigned short code_seg;
unsigned short opcode;
unsigned long operand;
unsigned short operand_seg;
unsigned short r3;
unsigned char regs[8][10];
};
void
fetch_inferior_registers (regno)
int regno;
{
struct reg inferior_registers;
struct env387 inferior_fpregisters;
ptrace (PT_GETREGS, inferior_pid,
(PTRACE_ARG3_TYPE) &inferior_registers, 0);
ptrace (PT_GETFPREGS, inferior_pid,
(PTRACE_ARG3_TYPE) &inferior_fpregisters, 0);
RF ( 0, inferior_registers.r_eax);
RF ( 1, inferior_registers.r_ecx);
RF ( 2, inferior_registers.r_edx);
RF ( 3, inferior_registers.r_ebx);
RF ( 4, inferior_registers.r_esp);
RF ( 5, inferior_registers.r_ebp);
RF ( 6, inferior_registers.r_esi);
RF ( 7, inferior_registers.r_edi);
RF ( 8, inferior_registers.r_eip);
RF ( 9, inferior_registers.r_eflags);
RF (10, inferior_registers.r_cs);
RF (11, inferior_registers.r_ss);
RF (12, inferior_registers.r_ds);
RF (13, inferior_registers.r_es);
RF (14, inferior_registers.r_fs);
RF (15, inferior_registers.r_gs);
RF (FP0_REGNUM, inferior_fpregisters.regs[0]);
RF (FP0_REGNUM + 1, inferior_fpregisters.regs[1]);
RF (FP0_REGNUM + 2, inferior_fpregisters.regs[2]);
RF (FP0_REGNUM + 3, inferior_fpregisters.regs[3]);
RF (FP0_REGNUM + 4, inferior_fpregisters.regs[4]);
RF (FP0_REGNUM + 5, inferior_fpregisters.regs[5]);
RF (FP0_REGNUM + 6, inferior_fpregisters.regs[6]);
RF (FP0_REGNUM + 7, inferior_fpregisters.regs[7]);
RF (FCTRL_REGNUM, inferior_fpregisters.control);
RF (FSTAT_REGNUM, inferior_fpregisters.status);
RF (FTAG_REGNUM, inferior_fpregisters.tag);
RF (FCS_REGNUM, inferior_fpregisters.code_seg);
RF (FCOFF_REGNUM, inferior_fpregisters.eip);
RF (FDS_REGNUM, inferior_fpregisters.operand_seg);
RF (FDOFF_REGNUM, inferior_fpregisters.operand);
RF (FOP_REGNUM, inferior_fpregisters.opcode);
registers_fetched ();
}
void
store_inferior_registers (regno)
int regno;
{
struct reg inferior_registers;
struct env387 inferior_fpregisters;
RS ( 0, inferior_registers.r_eax);
RS ( 1, inferior_registers.r_ecx);
RS ( 2, inferior_registers.r_edx);
RS ( 3, inferior_registers.r_ebx);
RS ( 4, inferior_registers.r_esp);
RS ( 5, inferior_registers.r_ebp);
RS ( 6, inferior_registers.r_esi);
RS ( 7, inferior_registers.r_edi);
RS ( 8, inferior_registers.r_eip);
RS ( 9, inferior_registers.r_eflags);
RS (10, inferior_registers.r_cs);
RS (11, inferior_registers.r_ss);
RS (12, inferior_registers.r_ds);
RS (13, inferior_registers.r_es);
RS (14, inferior_registers.r_fs);
RS (15, inferior_registers.r_gs);
RS (FP0_REGNUM, inferior_fpregisters.regs[0]);
RS (FP0_REGNUM + 1, inferior_fpregisters.regs[1]);
RS (FP0_REGNUM + 2, inferior_fpregisters.regs[2]);
RS (FP0_REGNUM + 3, inferior_fpregisters.regs[3]);
RS (FP0_REGNUM + 4, inferior_fpregisters.regs[4]);
RS (FP0_REGNUM + 5, inferior_fpregisters.regs[5]);
RS (FP0_REGNUM + 6, inferior_fpregisters.regs[6]);
RS (FP0_REGNUM + 7, inferior_fpregisters.regs[7]);
RS (FCTRL_REGNUM, inferior_fpregisters.control);
RS (FSTAT_REGNUM, inferior_fpregisters.status);
RS (FTAG_REGNUM, inferior_fpregisters.tag);
RS (FCS_REGNUM, inferior_fpregisters.code_seg);
RS (FCOFF_REGNUM, inferior_fpregisters.eip);
RS (FDS_REGNUM, inferior_fpregisters.operand_seg);
RS (FDOFF_REGNUM, inferior_fpregisters.operand);
RS (FOP_REGNUM, inferior_fpregisters.opcode);
ptrace (PT_SETREGS, inferior_pid,
(PTRACE_ARG3_TYPE) &inferior_registers, 0);
ptrace (PT_SETFPREGS, inferior_pid,
(PTRACE_ARG3_TYPE) &inferior_fpregisters, 0);
}
struct md_core
{
struct reg intreg;
struct fpreg freg;
};
void
fetch_core_registers (core_reg_sect, core_reg_size, which, ignore)
char *core_reg_sect;
unsigned core_reg_size;
int which;
CORE_ADDR ignore;
{
struct md_core *core_reg = (struct md_core *) core_reg_sect;
/* integer registers */
memcpy (®isters[REGISTER_BYTE (0)], &core_reg->intreg,
sizeof (struct reg));
/* floating point registers */
/* XXX */
}
--
J.T. Conklin
RedBack Networks
From Stephane.Carrez@worldnet.fr Tue Mar 21 13:15:00 2000
From: Stephane Carrez <Stephane.Carrez@worldnet.fr>
To: Andrew Cagney <ac131313@cygnus.com>, gdb-patches@sourceware.cygnus.com
Subject: Re: path for gdb/dwarf2read.c, support 16-bit targets in dwarf-2
Date: Tue, 21 Mar 2000 13:15:00 -0000
Message-id: <38D7E6BC.79543EBA@worldnet.fr>
References: <38D4DCB0.88313CB2@worldnet.fr> <38D5B6E0.50FF6A5E@cygnus.com> <38D68C56.856CB00C@worldnet.fr> <38D74A9E.A85ED8EC@cygnus.com>
X-SW-Source: 2000-03/msg00435.html
Content-length: 1810
Hi Andrew,
Andrew Cagney wrote:
>
> As far as I know, the dwarf2 and elf information are both ment to be
> self contained. There shouldn't be any need to refer to some arbitrary
> bfd table to determine what is going on. If the info says that an
> address is 16 bits for a given section then it sounds like GDB should
> just believe it.
>
Ok
> As JimK suggested:
> > Or to put it another way, specifically what went wrong on the 68HC11
> > if you didn't change dwarf2read.c? If it was just the "Dwarf Error:
> > bad address size" error, what happens if you just comment out that
> > check?
>
> Rather than diging values out of archures I think the possibility of:
> cu_header.address_size < elf-header.address_size
> should be documented as being just as legetimate (sarcasm :-) as:
> cu_header.address_size > elf-header.address_size
> and the check either replaced or removed.
>
> Andrew
Ok, lets remove the strange test (it does not exist in bfd/dwarf2.c
nor in readelf.c...)
Thanks,
Stephane
2000-03-21 Stephane Carrez <stcarrez@worldnet.fr>
* dwarf2read.c (dwarf2_build_psymtabs_hard): Do not check
the dwarf address size against elf address size.
--- /src/gnu/cygnus/gdb/gdb/dwarf2read.c Sat Mar 4 11:38:38 2000
+++ gdb/dwarf2read.c Tue Mar 21 20:50:13 2000
@@ -980,12 +980,6 @@ dwarf2_build_psymtabs_hard (objfile, mai
(long) (beg_of_comp_unit - dwarf_info_buffer));
return;
}
- if (address_size < address_significant_size)
- {
- error ("Dwarf Error: bad address size (%ld) in compilation unit header (offset 0x%lx + 11).",
- (long) cu_header.addr_size,
- (long) (beg_of_comp_unit - dwarf_info_buffer));
- }
/* Read the abbrevs for this compilation unit into a table */
dwarf2_read_abbrevs (abfd, cu_header.abbrev_offset);
From msnyder@cygnus.com Tue Mar 21 14:09:00 2000
From: Michael Snyder <msnyder@cygnus.com>
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH] Running the inferior from breakpoint commands
Date: Tue, 21 Mar 2000 14:09:00 -0000
Message-id: <38D7F31D.1827@cygnus.com>
References: <200003120759.CAA24402@indy.delorie.com> <200003151624.LAA01228@indy.delorie.com>
X-SW-Source: 2000-03/msg00436.html
Content-length: 8368
Eli Zaretskii wrote:
>
> This is about the problem described in the following message:
>
> http://sourceware.cygnus.com/ml/gdb/2000-q1/msg00684.html
>
> The relevant test cases are in gdb/testsuite/gdb.base/commands.exp.
Eli,
While this is intriguing, I don't think it's as simple as
you suppose. In the first place, it is a documented limitation
that GDB only partially handles breakpoint command lists if they
contain commands that run the target. The GDB manual states:
You can use breakpoint commands to start your program
up again. Simply use the continue command, or step,
or any other command that resumes execution. Any
other commands in the command list are ignored, after
a command that resumes execution.
Note the last sentence. So despite the fact that the
testsuite seems to imply that this should work, it is
not expected to. I have no idea what that test is
doing in there. The commands-on-breakpoint behavior
is NOT intended to be recursive.
Therefore what you are trying to do is more of an
enhancement than a bug fix. As such, I would need to
see some new tests; and given the difficulty of solving
this problem correctly, they would have to be pretty
thorough. I would have to see tests for every kind of
execution command (step, next, call, finish, return, etc.)
combined with a wide variety of "things that could go
wrong (expression evaluation using globals, locals,
recursive vs. non-recursive functions, multiple
breakpoints on mutually recursive functions...)
If you seriously want to undertake this project, we can
work on a list of criteria that should be tested (things
that can go wrong). Off the top of my head, I can think
of:
* What happens if we continue and hit another BP?
* What happens if we continue and hit the same
BP, eg. in a recursive function?
* What happens if we continue and switch threads?
* What happens if we continue and the program terminates?
* What happens if we continue, hit another BP,
then that BP continues and we hit the first BP?
* What happens if the program isn't continuable?
On top of that, I have grave concerns about being able
to correctly save and restore all of the internal
debugger state necessary to make this work (the
infrun execution state, the expression chain, etc.)
Not to discourage you from trying it, but I would be
very suspicious of any effort that only took a few days
to complete.
Sincerely,
Michael Snyder
> Here are the patches which correct the problems I described in the
> original message. After applying them, the test program works as I'd
> expect (and as commands.exp seems to want).
>
> I didn't see any replies to my message, so I still don't know whether
> the original code works for other platforms (I think it shouldn't).
> Could someone please try commands.exp and tell what you get?
>
> Please tell if it's okay to commit these changes. If they are
> accepted, I will also send changes for the docs, since I think there
> are some limitations on what breakpoint commands can do that should be
> documented.
>
> 2000-03-14 Eli Zaretskii <eliz@is.elta.co.il>
>
> * breakpoint.c (breakpoint_alive_p): New function.
> (bpstat_do_actions): Allow recursive invocation, provided that the
> argument isn't identical to the one last seen. Stop executing
> commands if their breakpoint no longer exists (e.g., was deleted
> by the previous command). Save and restore the bpstat chain if
> the command proceeded the inferior. Invoke bpstat_do_actions
> recursively to process the new bpstat produced when the proceeding
> inferior stops.
>
> --- gdb/breakpoint.c~3 Wed Mar 8 20:02:20 2000
> +++ gdb/breakpoint.c Tue Mar 14 18:17:50 2000
> @@ -1820,6 +1820,20 @@ bpstat_clear_actions (bs)
> }
> }
>
> +/* Is the breakpoint BPT still defined? */
> +static int
> +breakpoint_alive_p (bpt)
> + struct breakpoint *bpt;
> +{
> + struct breakpoint *b;
> +
> + ALL_BREAKPOINTS (b)
> + if (b == bpt)
> + return 1;
> +
> + return 0;
> +}
> +
> /* Stub for cleaning up our state if we error-out of a breakpoint command */
> /* ARGSUSED */
> static void
> @@ -1838,19 +1852,23 @@ void
> bpstat_do_actions (bsp)
> bpstat *bsp;
> {
> - bpstat bs;
> + static bpstat last_bpstat;
> + bpstat bs, saved_bs;
> struct cleanup *old_chain;
> struct command_line *cmd;
> + int bs_idx, cmd_idx;
>
> /* Avoid endless recursion if a `source' command is contained
> in bs->commands. */
> - if (executing_breakpoint_commands)
> + if (executing_breakpoint_commands
> + && memcmp (bsp, &last_bpstat, sizeof (*bsp)) == 0)
> return;
>
> + last_bpstat = *bsp;
> +
> executing_breakpoint_commands = 1;
> old_chain = make_cleanup (cleanup_executing_breakpoints, 0);
>
> -top:
> /* Note that (as of this writing), our callers all appear to
> be passing us the address of global stop_bpstat. And, if
> our calls to execute_control_command cause the inferior to
> @@ -1863,26 +1881,78 @@ top:
> bs = *bsp;
>
> breakpoint_proceeded = 0;
> - for (; bs != NULL; bs = bs->next)
> + for (bs_idx = 0; bs != NULL; bs = bs->next, bs_idx++)
> {
> + /* If someone deleted the breakpoint associated with this
> + bpstat, we cannot run its commands, since deleting a
> + breakpoint nukes its command lines. */
> + if (!breakpoint_alive_p (bs->breakpoint_at))
> + continue;
> cmd = bs->commands;
> + cmd_idx = 0;
> while (cmd != NULL)
> {
> + struct cleanup *pchain;
> + int idx;
> +
> + saved_bs = bpstat_copy (*bsp);
> + pchain = make_cleanup ((make_cleanup_func)bpstat_clear, &saved_bs);
> execute_control_command (cmd);
>
> if (breakpoint_proceeded)
> + {
> + /* The inferior is proceeded by the command. We cannot
> + continue, as the bpstat chain has been blown away by
> + wait_for_inferior. But since execution has stopped
> + again, there is a new bpstat to look at, so start
> + over. */
> + bpstat_do_actions (bsp);
> +
> + /* Now we need to proceed with any actions of the old
> + bpstat chain which are still not done. But first, we
> + need to restore the old chain, since it was blown
> + away. */
> + *bsp = saved_bs;
> + bs = *bsp;
> + last_bpstat = *bsp;
> +
> + /* Recursive invocation of bpstat_do_actions could reset
> + breakpoint_proceeded and
> + executing_breakpoint_commands, so restore their
> + values. */
> + breakpoint_proceeded = 1;
> + executing_breakpoint_commands = 1;
> +
> + /* Skip all the actions that were already done. */
> + for (idx = 0; idx < bs_idx; idx++)
> + {
> + bs->commands = NULL;
> + bs = bs->next;
> + }
> + cmd = bs->commands;
> + }
> + else
> + {
> + bpstat_clear (&saved_bs);
> + discard_cleanups (pchain);
> + }
> + cmd_idx++;
> + /* The command we just ran could have deleted the
> + breakpoint. This nukes the command lines for this
> + breakpoint, so we cannot continue them. */
> + if (!breakpoint_alive_p (bs->breakpoint_at))
> break;
> + if (breakpoint_proceeded)
> + {
> + /* Skip the commands we already ran. */
> + for (idx = 0; idx < cmd_idx; idx++)
> + cmd = cmd->next;
> + breakpoint_proceeded = 0;
> + }
> else
> cmd = cmd->next;
> }
> - if (breakpoint_proceeded)
> - /* The inferior is proceeded by the command; bomb out now.
> - The bpstat chain has been blown away by wait_for_inferior.
> - But since execution has stopped again, there is a new bpstat
> - to look at, so start over. */
> - goto top;
> - else
> - bs->commands = NULL;
> + bs->commands = NULL;
> }
>
> executing_breakpoint_commands = 0;
From ac131313@cygnus.com Tue Mar 21 14:21:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: jtc@redback.com
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: RFA: tm-nbsd.h: define IN_SOLIB_CALL_TRAMPOLINE
Date: Tue, 21 Mar 2000 14:21:00 -0000
Message-id: <38D7F5B5.D7D157BA@cygnus.com>
References: <5maejsgjl8.fsf@jtc.redbacknetworks.com>
X-SW-Source: 2000-03/msg00437.html
Content-length: 1086
"J.T. Conklin" wrote:
>
> I submit the enclosed patch for approval. This allows programs linked
> with shared libraries to be debugged on a.out-based NetBSD targets.
>
> 2000-03-21 J.T. Conklin <jtc@redback.com>
>
> * tm-nbsd.h (IN_SOLIB_CALL_TRAMPOLINE): Define if not
> SVR4_SHARED_LIBS.
>
> Index: tm-nbsd.h
> ===================================================================
> RCS file: /cvs/src/src/gdb/config/tm-nbsd.h,v
> retrieving revision 1.1.1.2
> diff -c -3 -p -r1.1.1.2 tm-nbsd.h
> *** tm-nbsd.h 1999/07/07 20:11:33 1.1.1.2
> --- tm-nbsd.h 2000/03/21 20:17:52
> ***************
> *** 18,20 ****
> --- 18,29 ----
> along with this program; if not, write to the Free Software
> Foundation, Inc., 59 Temple Place - Suite 330,
> Boston, MA 02111-1307, USA. */
> +
> + #ifndef SVR4_SHARED_LIBS
> +
> + /* Return non-zero if we are in a shared library trampoline code stub. */
> +
> + #define IN_SOLIB_CALL_TRAMPOLINE(pc, name) \
> + (name && !strcmp(name, "_DYNAMIC"))
> +
> + #endif /* !SVR4_SHARED_LIBS */
Approved.
Andrew
From ac131313@cygnus.com Tue Mar 21 14:22:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: jtc@redback.com
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: RFA: i386/tm-nsbd.h, i386/nm-nbsd.h
Date: Tue, 21 Mar 2000 14:22:00 -0000
Message-id: <38D7F5FC.8D45CBAF@cygnus.com>
References: <5m66uggiur.fsf@jtc.redbacknetworks.com>
X-SW-Source: 2000-03/msg00438.html
Content-length: 375
"J.T. Conklin" wrote:
>
> I submit the enclosed patch for approval. These changes enable
> floating point register support on NetBSD/i386.
>
> --jtc
>
> 2000-03-21 J.T. Conklin <jtc@redback.com>
>
> * i386/tm-nbsd.h (NUM_REGS): Removed.
> (HAVE_I387_REGS): Defined.
> * i386/nm-nbsd.h (FLOAT_INFO): Removed.
Approved (thanks).
Andrew
From ac131313@cygnus.com Tue Mar 21 14:28:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: jtc@redback.com
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: RFA: i386/nbsd.mt, i386nbsd-nat.c
Date: Tue, 21 Mar 2000 14:28:00 -0000
Message-id: <38D7F75F.522996A3@cygnus.com>
References: <5m1z54gif1.fsf@jtc.redbacknetworks.com>
X-SW-Source: 2000-03/msg00439.html
Content-length: 665
"J.T. Conklin" wrote:
>
> I submit the enclosed patch for approval. This change splits out
> NetBSD native support from the FreeBSD, BSDI, and 386BSD support. The
> changes I submitted earlier today convert the NetBSD target to use the
> generic floating point register support, which conflicts with i386b-nat.c
>
> --jtc
>
> 2000-03-21 J.T. Conklin <jtc@redback.com>
>
> * i386/nbsd.mh (NATDEPFILES): Changed i386b-nat.c to i386nbsd-nat.c.
> * i386nbsd-nat.c: New file.
Ok. (The naming schema *-nat.c files is AWAL. Your consistent with
other *bsd targets :-)
Last time I tried FreeBSD couldn't build GDB native anyway.
Andrew
From ac131313@cygnus.com Tue Mar 21 14:42:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Jimmy Guo <guo@cup.hp.com>
Cc: Michael Snyder <msnyder@cygnus.com>, John David Anglin <dave@hiauly1.hia.nrc.ca>, gdb-patches@sourceware.cygnus.com
Subject: Re: Initialization of hpux_threads
Date: Tue, 21 Mar 2000 14:42:00 -0000
Message-id: <38D7F9C4.ECF7E17F@cygnus.com>
References: <Pine.LNX.4.10.10003211208350.31096-100000@hpcll168.cup.hp.com>
X-SW-Source: 2000-03/msg00440.html
Content-length: 1706
Jimmy Guo wrote:
>
> On Fri, 17 Mar 2000, Michael Snyder wrote:
>
> >John David Anglin wrote:
> >>
> >> Thu Mar 16 16:49:27 EST 2000 John David Anglin <dave@hiauly1.hia.nrc.ca>
> >>
> >> * configure.in: Don't call _initialize_hpux_thread twice.
> >> * configure: Regenerated.
> >>
> >> --- configure.in.orig Mon Mar 6 18:30:12 2000
> >> +++ configure.in Thu Mar 16 14:22:26 2000
> >> @@ -330,7 +330,6 @@
> >> AC_DEFINE(HAVE_HPUX_THREAD_SUPPORT)
> >> CONFIG_OBS="${CONFIG_OJS} hpux-thread.o"
> >> CONFIG_SRCS="${CONFIG_SRCS} hpux-thread.c"
> >> - CONFIG_INITS="${CONFIG_INITS} hpux-thread.c"
> >> else
> >> AC_MSG_RESULT(no (suppressed because you are not using GCC))
> >> fi
> >
> >If someone from HP will approve this, I will check it in...
> >
> > Michael Snyder
>
> This looks fine. Just an observation:
> CONFIG_OBS is part of DEPFILES, which is part of COMMON_OBS, which is
> part of OBS, which is part of INITFILES. It looks like all three usages
> of CONFIG_INITS in configure.in can be removed. Maybe you can just
> remove CONFIG_INITS altogether in configure.in and Makefile.in. Since
> OBS file list is already looked at by init.c rule, it really makes no
> sense to maintain a CONFIG_INITS file list.
No. CONFIG_INITS was added because things get complicated when adding
sub-directory files (eg MI) that contain _initialize_*() functions. The
mistake was to assume that it was needed in all (rather than special)
cases.
By doing this the MI avoided the need to add any nasty initialization
hooks to main() - unlike tui, MPW, and GDBTK.
Andrew
From fnasser@cygnus.com Tue Mar 21 14:46:00 2000
From: Fernando Nasser <fnasser@cygnus.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: "Peter.Schauer" <Peter.Schauer@regent.e-technik.tu-muenchen.de>, gdb-patches@sourceware.cygnus.com
Subject: Re: RFD: printcmd.c: Changing output width of p/a and x/a
Date: Tue, 21 Mar 2000 14:46:00 -0000
Message-id: <38D7F978.75E55A39@cygnus.com>
References: <200003072113.WAA26267@reisser.regent.e-technik.tu-muenchen.de> <38D5EB6E.61C7D7D1@cygnus.com>
X-SW-Source: 2000-03/msg00441.html
Content-length: 2306
Andrew Cagney wrote:
>
> "Peter.Schauer" wrote:
>
> > Would you expect
> >
> > (gdb) p/a (char)-1
>
> (I guess you mean ``(signed char) -1''
> >
> > to yield
> >
> > $1 = 0xff (truncation to length of value, will cause testsuite
> > regressions, which have to be adressed by changing
> > the expect patterns)
> > or
> >
> > $1 = 0xffffffff (truncation to size of pointer)
>
> I suspect the latter. The value is being printed as if it were being
> interpreted as an address (but I'm not the CLI expert).
>
I agree as well. "a" stands for address -- it is always better to show it in a consistent size.
> >
> > Here is a patch to truncate to the size of a pointer, please let me know
> > if you want this to be changed to truncate to the length of the value.
> >
> > 2000-03-07 Peter Schauer <pes@regent.e-technik.tu-muenchen.de>
> >
> > * printcmd.c (print_scalar_formatted): Truncate addresses to the
> > size of a target pointer before passing them to print_address.
> >
> > *** ./printcmd.c.orig Sun Mar 5 17:35:36 2000
> > --- ./printcmd.c Tue Mar 7 19:59:46 2000
> > ***************
> > *** 443,449 ****
> > break;
> >
> > case 'a':
> > ! print_address (unpack_pointer (type, valaddr), stream);
> > break;
> >
> > case 'c':
> > --- 443,455 ----
> > break;
> >
> > case 'a':
> > ! {
> > ! /* Truncate address to the size of a target pointer. */
> > ! CORE_ADDR addr = unpack_pointer (type, valaddr);
> > ! if (TARGET_PTR_BIT < (sizeof (CORE_ADDR) * HOST_CHAR_BIT))
> > ! addr &= ((CORE_ADDR) 1 << TARGET_PTR_BIT) - 1;
> > ! print_address (addr, stream);
> > ! }
> > break;
>
> I'd include a comment noteing that shifting by
> sizeof(CORE_ADDR)*HOST_CHAR_BIT is dangerous.
>
I am not the maintainer of printcmd.c, but as it is remotely related to the command line user interface I would at least
vote in favor of it (with the addition of the comment suggested by Andrew).
--
Fernando Nasser
Red Hat - Toronto E-Mail: fnasser@cygnus.com
2323 Yonge Street, Suite #300 Tel: 416-482-2661 ext. 311
Toronto, Ontario M4P 2C9 Fax: 416-482-6299
From kevinb@cygnus.com Tue Mar 21 14:54:00 2000
From: Kevin Buettner <kevinb@cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Subject: [PATCH] symtab.h, symfile.h, symfile.c, and solib.c changes
Date: Tue, 21 Mar 2000 14:54:00 -0000
Message-id: <1000321225350.ZM26428@ocotillo.lan>
X-SW-Source: 2000-03/msg00442.html
Content-length: 8162
I just committed the following changes. I've built/run the test suite
on three platforms (linux/ia32, linux/ia64, linux/ppc) and all looks
well.
* symtab.h (MAX_SECTIONS, struct section_addr_info,
symbol_file_add): Move declarations from here...
* symfile.h: ...to here.
* solib.c (symbol_add_stub): Make symbol_file_add () aware of
all section addresses, not just .text.
* symfile.h, symfile.c (free_section_addr_info,
build_section_addr_info_from_section_table): New functions.
* symfile.h (MAX_SECTIONS): Increase value to 40.
* symfile.c (syms_from_objfile): Add bounds check prior to
accessing ``other'' array in a section_addr_info_struct.
Remove unused variable section_offsets.
(add_symbol_file_command): Remove unused variable text_addr.
Index: solib.c
===================================================================
RCS file: /cvs/src/src/gdb/solib.c,v
retrieving revision 1.5
diff -u -p -r1.5 solib.c
--- solib.c 2000/03/17 20:12:23 1.5
+++ solib.c 2000/03/21 22:12:33
@@ -1155,6 +1155,7 @@ symbol_add_stub (arg)
{
register struct so_list *so = (struct so_list *) arg; /* catch_errs bogon */
CORE_ADDR text_addr = 0;
+ struct section_addr_info *sap;
/* Have we already loaded this shared object? */
ALL_OBJFILES (so->objfile)
@@ -1181,15 +1182,12 @@ symbol_add_stub (arg)
+ LM_ADDR (so);
}
- {
- struct section_addr_info section_addrs;
-
- memset (§ion_addrs, 0, sizeof (section_addrs));
- section_addrs.text_addr = text_addr;
-
- so->objfile = symbol_file_add (so->so_name, so->from_tty,
- §ion_addrs, 0, OBJF_SHARED);
- }
+ sap = build_section_addr_info_from_section_table (so->sections,
+ so->sections_end);
+ sap->text_addr = text_addr;
+ so->objfile = symbol_file_add (so->so_name, so->from_tty,
+ sap, 0, OBJF_SHARED);
+ free_section_addr_info (sap);
return (1);
}
Index: symfile.c
===================================================================
RCS file: /cvs/src/src/gdb/symfile.c,v
retrieving revision 1.2
diff -u -p -r1.2 symfile.c
--- symfile.c 2000/03/15 19:43:57 1.2
+++ symfile.c 2000/03/21 22:12:37
@@ -461,6 +461,58 @@ find_lowest_section (abfd, sect, obj)
*lowest = sect;
}
+
+/* Build (allocate and populate) a section_addr_info struct from
+ an existing section table. */
+
+extern struct section_addr_info *
+build_section_addr_info_from_section_table (const struct section_table *start,
+ const struct section_table *end)
+{
+ struct section_addr_info *sap;
+ const struct section_table *stp;
+ int oidx;
+
+ sap = xmalloc (sizeof (struct section_addr_info));
+ memset (sap, 0, sizeof (struct section_addr_info));
+
+ for (stp = start, oidx = 0; stp != end; stp++)
+ {
+ if (strcmp (stp->the_bfd_section->name, ".text") == 0)
+ sap->text_addr = stp->addr;
+ else if (strcmp (stp->the_bfd_section->name, ".data") == 0)
+ sap->data_addr = stp->addr;
+ else if (strcmp (stp->the_bfd_section->name, ".bss") == 0)
+ sap->bss_addr = stp->addr;
+
+ if (stp->the_bfd_section->flags & (SEC_ALLOC | SEC_LOAD)
+ && oidx < MAX_SECTIONS)
+ {
+ sap->other[oidx].addr = stp->addr;
+ sap->other[oidx].name = xstrdup (stp->the_bfd_section->name);
+ sap->other[oidx].sectindex = stp->the_bfd_section->index;
+ oidx++;
+ }
+ }
+
+ return sap;
+}
+
+
+/* Free all memory allocated by build_section_addr_info_from_section_table. */
+
+extern void
+free_section_addr_info (struct section_addr_info *sap)
+{
+ int idx;
+
+ for (idx = 0; idx < MAX_SECTIONS; idx++)
+ if (sap->other[idx].name)
+ free (sap->other[idx].name);
+ free (sap);
+}
+
+
/* Parse the user's idea of an offset for dynamic linking, into our idea
of how to represent it for fast symbol reading. This is the default
version of the sym_fns.sym_offsets function for symbol readers that
@@ -531,7 +583,6 @@ syms_from_objfile (objfile, addrs, mainl
int mainline;
int verbo;
{
- struct section_offsets *section_offsets;
asection *lower_sect;
asection *sect;
CORE_ADDR lower_offset;
@@ -738,7 +789,9 @@ syms_from_objfile (objfile, addrs, mainl
else if (strcmp (s->the_bfd_section->name, ".bss") == 0)
s_addr = addrs->bss_addr;
else
- for (i = 0; !s_addr && addrs->other[i].name; i++)
+ for (i = 0;
+ !s_addr && i < MAX_SECTIONS && addrs->other[i].name;
+ i++)
if (strcmp (s->the_bfd_section->name, addrs->other[i].name) == 0)
s_addr = addrs->other[i].addr; /* end added for gdb/13815 */
@@ -1460,7 +1513,6 @@ add_symbol_file_command (args, from_tty)
int from_tty;
{
char *name = NULL;
- CORE_ADDR text_addr;
int flags = OBJF_USERLOADED;
char *arg;
int expecting_option = 0;
Index: symfile.h
===================================================================
RCS file: /cvs/src/src/gdb/symfile.h,v
retrieving revision 1.1.1.6
diff -u -p -r1.1.1.6 symfile.h
--- symfile.h 1999/10/19 02:46:39 1.1.1.6
+++ symfile.h 2000/03/21 22:12:37
@@ -54,6 +54,29 @@ struct psymbol_allocation_list
int size;
};
+/* Define an array of addresses to accommodate non-contiguous dynamic
+ loading of modules. This is for use when entering commands, so we
+ can keep track of the section names until we read the file and
+ can map them to bfd sections. This structure is also used by
+ solib.c to communicate the section addresses in shared objects to
+ symbol_file_add (). */
+
+#define MAX_SECTIONS 40
+struct section_addr_info
+{
+ /* Sections whose names are always known to gdb. */
+ CORE_ADDR text_addr;
+ CORE_ADDR data_addr;
+ CORE_ADDR bss_addr;
+ /* Sections whose names are file format dependant. */
+ struct other_sections
+ {
+ CORE_ADDR addr;
+ char *name;
+ int sectindex;
+ } other[MAX_SECTIONS];
+};
+
/* Structure to keep track of symbol reading functions for various
object file types. */
@@ -162,6 +185,23 @@ syms_from_objfile PARAMS ((struct objfil
extern void
new_symfile_objfile PARAMS ((struct objfile *, int, int));
+
+extern struct objfile *
+symbol_file_add PARAMS ((char *, int, struct section_addr_info *, int, int));
+
+/* Build (allocate and populate) a section_addr_info struct from
+ an existing section table. */
+
+struct section_table;
+extern struct section_addr_info *
+build_section_addr_info_from_section_table (const struct section_table *start,
+ const struct section_table *end);
+
+/* Free all memory allocated by build_section_addr_info_from_section_table. */
+
+extern void
+free_section_addr_info (struct section_addr_info *);
+
extern struct partial_symtab *
start_psymtab_common PARAMS ((struct objfile *, struct section_offsets *,
Index: symtab.h
===================================================================
RCS file: /cvs/src/src/gdb/symtab.h,v
retrieving revision 1.3
diff -u -p -r1.3 symtab.h
--- symtab.h 2000/03/14 19:58:02 1.3
+++ symtab.h 2000/03/21 22:12:39
@@ -837,27 +837,6 @@ struct section_offsets
(sizeof (struct section_offsets) \
+ sizeof (((struct section_offsets *) 0)->offsets) * (SECT_OFF_MAX-1))
-/* Define an array of addresses to accommodate non-contiguous dynamic
- loading of modules. This is for use when entering commands, so we
- can keep track of the section names until we read the file and
- can map them to bfd sections. */
-
-#define MAX_SECTIONS 12
-struct section_addr_info
-{
- /* Sections whose names are always known to gdb. */
- CORE_ADDR text_addr;
- CORE_ADDR data_addr;
- CORE_ADDR bss_addr;
- /* Sections whose names are file format dependant. */
- struct other_sections
- {
- CORE_ADDR addr;
- char *name;
- int sectindex;
- } other[MAX_SECTIONS];
-};
-
/* Each source file or header is represented by a struct symtab.
These objects are chained through the `next' field. */
@@ -1436,9 +1415,6 @@ extern struct symtab *
extern void
clear_solib PARAMS ((void));
-
-extern struct objfile *
-symbol_file_add PARAMS ((char *, int, struct section_addr_info *, int, int));
/* source.c */
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: gdb.texinfo broken?
2000-03-21 11:31 ` gdb.texinfo broken? J.T. Conklin
@ 2000-03-21 14:56 ` Andrew Cagney
2000-04-01 0:00 ` Dmitry Sivachenko
1 sibling, 0 replies; 3+ messages in thread
From: Andrew Cagney @ 2000-03-21 14:56 UTC (permalink / raw)
To: Stan Shebs; +Cc: Michael Snyder, gdb-patches
"J.T. Conklin" wrote:
> It looks like the changes to the directory entry require the latest
> makeinfo. I tried to use makeinfo from texinfo-3.2 and it failed,
> makeinfo from texinfo-4.0 works.
From memory, the possibility of requiring texinfo 4.0 as part of
building GDB 5 was considered and rejected :-(
oops,
Andrew
From tromey@cygnus.com Tue Mar 21 15:03:00 2000
From: Tom Tromey <tromey@cygnus.com>
To: "Peter.Schauer" <Peter.Schauer@Regent.E-Technik.TU-Muenchen.DE>
Cc: gdb-patches@sourceware.cygnus.com, tromey@cygnus.com
Subject: Re: RFA: minsyms.c: Fixes for serious demangled hash minsym lookup flaws.
Date: Tue, 21 Mar 2000 15:03:00 -0000
Message-id: <200003212303.PAA22345@ferrule.cygnus.com>
References: <200003212002.VAA19812@reisser.regent.e-technik.tu-muenchen.de>
X-SW-Source: 2000-03/msg00444.html
Content-length: 436
>>>>> "Peter" == Peter Schauer <Peter.Schauer@Regent.E-Technik.TU-Muenchen.DE> writes:
Peter> There are two serious problems with the new demangled hash
Peter> minsym lookup code, causing lookup of demangled names to fail.
This would be my fault. Thanks.
Note that when I wrote this patch, I did before-and-after testing
against the gdb test suite with no regressions. It would be nice if
there were test cases for this code.
Tom
From kevinb@cygnus.com Tue Mar 21 15:07:00 2000
From: Kevin Buettner <kevinb@cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Subject: [PATCH] gdb.base/pointers.c commit
Date: Tue, 21 Mar 2000 15:07:00 -0000
Message-id: <1000321230718.ZM26524@ocotillo.lan>
X-SW-Source: 2000-03/msg00445.html
Content-length: 1828
I've just committed the change below. (This change was for AIX 4.3.)
* gdb.base/pointers.c (usevar): New function.
(main): Make sure that global variables v_int_pointer2, rptr,
and y are all referenced someplace in the program by calling
usevar() on them. [Some linkers delete symbols which are
never referenced. The space remains, but there's no way to
get a (symbolic) handle on the variable from the debugger.]
Index: gdb.base/pointers.c
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.base/pointers.c,v
retrieving revision 1.1.1.3
diff -u -p -r1.1.1.3 pointers.c
--- pointers.c 1999/08/02 23:46:51 1.1.1.3
+++ pointers.c 2000/03/21 22:59:17
@@ -71,35 +71,28 @@ float ** ptr_to_ptr_to_float;
int y;
+/* Do nothing function used for forcing some of the above variables to
+ be referenced by the program source. If the variables are not
+ referenced, some linkers will remove the symbol from the symbol
+ table making it impossible to refer to the variable in gdb. */
+void usevar (void *var) {}
+
int main ()
{
- void dummy();
- int more_code();
-
- /* Ensure that malloc is a pointer type; avoid use of "void" and any include files. */
- /* extern char *malloc();*/
-
- /* void *malloc(size_t);*/
-
-
-
+ void dummy();
+ int more_code();
+
#ifdef usestubs
set_debug_traps();
breakpoint();
#endif
dummy();
-/* v_int_pointer2 = &v_int_pointer;
- v_unsigned_int_pointer = &v_int;
-
- y = (v_unsigned_int_pointer == v_double_pointer);
-
- x = v_unsigned_int_pointer * v_double_pointer;
-
- v_unsigned_int_pointer = v_double_pointer;
-
- v_unsigned_int_pointer = v_unsigned_int;*/
more_code ();
+
+ usevar (&v_int_pointer2);
+ usevar (&rptr);
+ usevar (&y);
return 0;
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: gdb.texinfo broken?
2000-03-21 11:31 ` gdb.texinfo broken? J.T. Conklin
2000-03-21 14:56 ` Andrew Cagney
@ 2000-04-01 0:00 ` Dmitry Sivachenko
1 sibling, 0 replies; 3+ messages in thread
From: Dmitry Sivachenko @ 2000-04-01 0:00 UTC (permalink / raw)
To: jtc; +Cc: msnyder, eliz, gdb-patches
Please, do not hurry to back out @dircategory!
It was introduced somewhere in texinfo-3.*! The problem is somewhere else.
I'll try to figure it out...
--dima
From jimb@zwingli.cygnus.com Sat Apr 01 00:00:00 2000
From: Jim Blandy <jimb@zwingli.cygnus.com>
To: Stephane Carrez <Stephane.Carrez@worldnet.fr>
Cc: Andrew Cagney <ac131313@cygnus.com>, gdb-patches@sourceware.cygnus.com
Subject: Re: path for gdb/dwarf2read.c, support 16-bit targets in dwarf-2
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <npem8w42bg.fsf@zwingli.cygnus.com>
References: <38D4DCB0.88313CB2@worldnet.fr> <38D5B6E0.50FF6A5E@cygnus.com> <38D68C56.856CB00C@worldnet.fr> <38D74A9E.A85ED8EC@cygnus.com> <38D7E6BC.79543EBA@worldnet.fr>
X-SW-Source: 2000-q1/msg01063.html
Content-length: 1641
I've reached the same conclusion on a project I'm doing right now. I
think this test is bogus.
> > Rather than diging values out of archures I think the possibility of:
> > cu_header.address_size < elf-header.address_size
> > should be documented as being just as legetimate (sarcasm :-) as:
> > cu_header.address_size > elf-header.address_size
> > and the check either replaced or removed.
> >
> > Andrew
>
> Ok, lets remove the strange test (it does not exist in bfd/dwarf2.c
> nor in readelf.c...)
>
> Thanks,
> Stephane
>
> 2000-03-21 Stephane Carrez <stcarrez@worldnet.fr>
>
> * dwarf2read.c (dwarf2_build_psymtabs_hard): Do not check
> the dwarf address size against elf address size.
> --------------171FF77269274D1E5CFD870E
> Content-Type: text/plain; charset=us-ascii;
> name="dwarf2read.c.diff"
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline;
> filename="dwarf2read.c.diff"
>
> --- /src/gnu/cygnus/gdb/gdb/dwarf2read.c Sat Mar 4 11:38:38 2000
> +++ gdb/dwarf2read.c Tue Mar 21 20:50:13 2000
> @@ -980,12 +980,6 @@ dwarf2_build_psymtabs_hard (objfile, mai
> (long) (beg_of_comp_unit - dwarf_info_buffer));
> return;
> }
> - if (address_size < address_significant_size)
> - {
> - error ("Dwarf Error: bad address size (%ld) in compilation unit header (offset 0x%lx + 11).",
> - (long) cu_header.addr_size,
> - (long) (beg_of_comp_unit - dwarf_info_buffer));
> - }
>
> /* Read the abbrevs for this compilation unit into a table */
> dwarf2_read_abbrevs (abfd, cu_header.abbrev_offset);
>
> --------------171FF77269274D1E5CFD870E--
>
>
From hjl@lucon.org Sat Apr 01 00:00:00 2000
From: "H . J . Lu" <hjl@lucon.org>
To: Jim Kingdon <kingdon@redhat.com>, msnyder@cygnus.com
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: GDB 5.0 2000-03-05
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <20000307161242.A485@lucon.org>
References: <38C2320A.E2134B29@cygnus.com> <20000305094341.A10426@lucon.org> <br9dojaan.fsf@rtl.cygnus.com> <20000306094553.B28105@lucon.org> <200003061753.MAA14567@devserv.devel.redhat.com>
X-SW-Source: 2000-q1/msg00567.html
Content-length: 3599
On Mon, Mar 06, 2000 at 12:53:59PM -0500, Jim Kingdon wrote:
> > Do you have URL for the bug report.
>
> As noted on issues50.html,
> http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=9565
> The Mozilla folks would be *very* happy if someone can track this one down.
>
This patch disable the thread_db interface by default. gdb works MUCH
better now with threaded programs, including the testcase above. May
I suggest for 5.0, we disable thread_db and fix whatever bugs we can
fix in linux-thread.c? I will take a closer look at linux-thread.c
when I find time.
Thanks.
H.J.
---
2000-03-07 H.J. Lu <hjl@gnu.org>
* Makefile.in (LIN_THREAD): New.
(LIN_THREAD_CFLAGS): New.
(INTERNAL_WARN_CFLAGS): Add $(LIN_THREAD_CFLAGS).
* config/i386/linux.mh (NATDEPFILES): Change lin-thread.o to
$(LIN_THREAD).
* configure.in (--enable-thread_db): New switch. Set LIN_THREAD
and LIN_THREAD_CFLAGS accordingly.
* configure: Regenerated.
Index: configure.in
===================================================================
RCS file: /work/cvs/gnu/gdb/gdb/configure.in,v
retrieving revision 1.1.1.6
diff -u -p -r1.1.1.6 configure.in
--- configure.in 2000/03/07 18:42:10 1.1.1.6
+++ configure.in 2000/03/07 23:47:24
@@ -789,6 +807,26 @@ AC_SUBST(CONFIG_ALL)
AC_SUBST(CONFIG_CLEAN)
AC_SUBST(CONFIG_INSTALL)
AC_SUBST(CONFIG_UNINSTALL)
+
+# Begin stuff to support --enable-thread_db
+AC_ARG_ENABLE(thread_db,
+[ --enable-thread_db Use the thread_db interface],
+[case "${enableval}" in
+ yes) thread_db=true ;;
+ no) thread_db=false ;;
+ *) thread_db=true;;
+esac])dnl
+
+LIN_THREAD=
+LIN_THREAD_CFLAGS=
+if test "${thread_db}" = "true"; then
+ LIN_THREAD="lin-thread.o"
+ LIN_THREAD_CFLAGS="-DUSE_LIN_THREAD"
+fi
+
+AC_SUBST(LIN_THREAD)
+AC_SUBST(LIN_THREAD_CFLAGS)
+# End stuff to support --enable-shared
# Begin stuff to support --enable-shared
AC_ARG_ENABLE(shared,
Index: Makefile.in
===================================================================
RCS file: /work/cvs/gnu/gdb/gdb/Makefile.in,v
retrieving revision 1.1.1.9
diff -u -p -r1.1.1.9 Makefile.in
--- Makefile.in 2000/03/07 18:42:08 1.1.1.9
+++ Makefile.in 2000/03/07 23:28:45
@@ -114,6 +114,10 @@ LIBIBERTY = ../libiberty/libiberty.a
MMALLOC = @MMALLOC@
MMALLOC_CFLAGS = @MMALLOC_CFLAGS@
+# Configured by the --enable-thread_db configure.
+LIN_THREAD = @LIN_THREAD@
+LIN_THREAD_CFLAGS = @LIN_THREAD_CFLAGS@
+
# Where is the BFD library? Typically in ../bfd.
BFD_DIR = ../bfd
BFD = $(BFD_DIR)/libbfd.a
@@ -271,7 +275,8 @@ INTERNAL_WARN_CFLAGS = \
$(CFLAGS) $(GLOBAL_CFLAGS) $(PROFILE_CFLAGS) \
$(GDB_CFLAGS) $(OPCODES_CFLAGS) $(READLINE_CFLAGS) \
$(BFD_CFLAGS) $(MMALLOC_CFLAGS) $(INCLUDE_CFLAGS) \
- $(INTL_CFLAGS) $(TUI_CFLAGS) $(ENABLE_CFLAGS) $(GDB_WARN_CFLAGS)
+ $(INTL_CFLAGS) $(TUI_CFLAGS) $(ENABLE_CFLAGS) \
+ $(LIN_THREAD_CFLAGS) $(GDB_WARN_CFLAGS)
INTERNAL_CFLAGS = $(INTERNAL_WARN_CFLAGS) $(GDB_WERROR_CFLAGS)
# LDFLAGS is specifically reserved for setting from the command line
Index: config/i386/linux.mh
===================================================================
RCS file: /work/cvs/gnu/gdb/gdb/config/i386/linux.mh,v
retrieving revision 1.1.1.2
diff -u -p -r1.1.1.2 linux.mh
--- config/i386/linux.mh 2000/01/18 17:07:18 1.1.1.2
+++ config/i386/linux.mh 2000/03/07 23:44:03
@@ -5,6 +5,6 @@ XDEPFILES= ser-tcp.o
NAT_FILE= nm-linux.h
NATDEPFILES= infptrace.o solib.o inftarg.o fork-child.o corelow.o \
- core-aout.o i386v-nat.o i386-linux-nat.o linux-thread.o lin-thread.o
+ core-aout.o i386-linux-nat.o linux-thread.o $(LIN_THREAD)
LOADLIBES = -ldl -rdynamic
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Steven Johnson <sbjohnson@ozemail.com.au>
Cc: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: Re: RFA: Deprecate remote protocol sequence-ID
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38DB24AB.7881FFA1@cygnus.com>
References: <38DAF122.3CA0E862@cygnus.com> <38DB0EE5.831CD611@ozemail.com.au>
X-SW-Source: 2000-q1/msg00981.html
Content-length: 1685
Steven Johnson wrote:
>
> Andrew Cagney wrote:
> >
> > I'd like to put forward the proposal that the sequence-id:
> >
> > $sequence-id:packet-data#checksum
> >
> > be clearly deprecated.
>
> I would actually prefer to see it properly defined to secure up
> communications between
> the target and GDB. (Obviously it would be selectable)
I agree that there should be a properly defined mechanism for reliably
transfering packets, just not this one as it affects the contents of a
packet. The good old theory of a clear separation of layers :-)
I think a simple reliable separate transport layer is needed. I'd even
go as far as a new packet wrapper (replacing $...#NN and +-).
> Can you give an example of how it restricts packet contents, other than
> having a colon as the third character in the packet.
That, to me is sufficient.
> A Target i'm writing can use them and seem to work fine? Although Ive
> had to make some interpretations in implementation because they are not well
> defined.
That ``not well defined'' bit is my problem. GDB can't rely on what a
target will do with a sequence-id because it is not well defined. The
target might discard the packet. The target might reply with the
contents from the last output buffer, the target might even just repeat
the operation (oops :-).
> Further if the Colon at position 3 is a problem, then don't use it. It
> seems to me
> that a function code of '0'-'9' is not used, so it would be easy to
> detect these functions
> and say 'Now using sequence-id' must check colon for verification. (Also
> I check second character and it also must be 0-9.)
Interesting idea. None of the targets I know do this.
Andrew
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Geoff Keating <geoffk@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: patch to psim for denormal values
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38DC5F3A.FE48DC2A@cygnus.com>
References: <200003250008.QAA31192@localhost.cygnus.com>
X-SW-Source: 2000-q1/msg01019.html
Content-length: 346
Geoff Keating wrote:
>
> gcc/testsuite/gcc.c-torture/execute/ieee/20000320-1.c was sending the
> sim into a very long (perhaps infinite) loop, because of this typo.
Wow! A bug :-)
> My copy of the ppc 601 user's manual correctly uses '+' here (on page
> F-2).
Oops, nothing like copying it down wrong.
> OK to commit?
Yes. Thanks.
Andrew
From jtc@redback.com Sat Apr 01 00:00:00 2000
From: jtc@redback.com (J.T. Conklin)
To: Mark Kettenis <kettenis@wins.uva.nl>
Cc: shebs@shebs.cnchost.com, dima@Chg.RU, eliz@is.elta.co.il, gdb-patches@sourceware.cygnus.com
Subject: Re: patch for gdb.texinfo
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <5mu2jrmjqt.fsf@jtc.redbacknetworks.com>
References: <200001281642.TAA04176@netserv1.chg.ru> <3891CD13.A68984BA@shebs.cnchost.com> <200001281909.e0SJ97M18034@delius.kettenis.local>
X-SW-Source: 2000-q1/msg00067.html
Content-length: 1298
>>>>> "Mark" == Mark Kettenis <kettenis@wins.uva.nl> writes:
Mark> Cygnus might do things a little different. Is GDB still
Mark> distributed with texinfo included? The CVS version suggests
Mark> that this is the case. Since the version in CVS is older than
Mark> texinfo 4.0, using new features would not be very convenient!
Mark> Maybe it is time for an upgrade?
The full texinfo distribution is not distributed with GDB releases, at
least it wasn't with gdb-4.16, 4.17, or 4.18. Those releases provided
only texinfo.tex, gpl.texinfo, lgpl.texinfo, and tex3patch.
However, a modified texinfo-3.2 is still distributed in GDB snapshots.
I managed to overwrite texinfo-4.0 on my system after installing a GDB
snapshot. I mentioned this at the time, hoping that texinfo would be
dropped from snapshots. Ultimately, I changed my import procedure to
remove texinfo before importing new snapshots into my own repository.
I notice that the binutils repository on sourceware only contains
texinfo.tex in it's texinfo directory. Now that the binutils and GDB
repositories are being merged, perhaps this problem will go away. I
hope that the reverse is not true and that binutils is not similarly
tainted with a obsolete texinfo distribution.
--jtc
--
J.T. Conklin
RedBack Networks
From msnyder@cygnus.com Sat Apr 01 00:00:00 2000
From: Michael Snyder <msnyder@cygnus.com>
To: "H . J . Lu" <hjl@lucon.org>
Cc: Mark Kettenis <kettenis@wins.uva.nl>, gdb-patches@sourceware.cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: A revised patch for dlclose
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38C69870.709F@cygnus.com>
References: <20000307120800.A27315@valinux.com> <200003080058.e280wga00453@delius.kettenis.local> <20000307170321.A884@lucon.org> <200003080119.e281Jul00524@delius.kettenis.local> <20000307173547.A1068@lucon.org>
X-SW-Source: 2000-q1/msg00598.html
Content-length: 1507
H . J . Lu wrote:
>
> On Wed, Mar 08, 2000 at 02:19:56AM +0100, Mark Kettenis wrote:
> > Date: Tue, 7 Mar 2000 17:03:21 -0800
> > From: "H . J . Lu" <hjl@lucon.org>
> > Cc: gdb-patches@sourceware.cygnus.com, gdb@sourceware.cygnus.com
> > Content-Type: text/plain; charset=us-ascii
> >
> > > HJ, please stop wasting your time pushing this patch. The patch has
> > > several bad points, that you cannot fix without considerable changes
> > > to the way solib.c handles and caches the link map.
> >
> > I just pointed out gdb needed to check the unloaded DSOs when handling
> > the BPSTAT_WHAT_CHECK_SHLIBS and BPSTAT_WHAT_CHECK_SHLIBS_RESUME_FROM_HOOK
> > events. It is a serious bug to me and it should be fixed in 5.0. I
> > don't care how it is fixed.
> >
> > But I, and I hope most of the other GDB maintainers, do care how it is
> > fixed!
>
> That is fine with me as long as it is fixed in 5.0. There is no excuse
> not to get gdb to work with dlclose. "I don't like the way it fixes the
> bug" doesn't count unless you can provide a different approach. I
> think it is unreasonable to have a perfect fix for every bug. We can
> work a better one after 5.0 if we don't have the time now.
I'm sorry, but I have to disagree. I'm not addressing your
patch in particular, but there are many "fixes" that are
worse than no fix at all. In fact, GDB is full of them,
to our (the maintainers) daily regret. There is never time
to fix it right the second time.
Michael
From Peter.Schauer@regent.e-technik.tu-muenchen.de Sat Apr 01 00:00:00 2000
From: "Peter.Schauer" <Peter.Schauer@regent.e-technik.tu-muenchen.de>
To: gdb-patches@sourceware.cygnus.com
Subject: RFA: maint.c: Add `mt i' alias for `mt info'
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003271537.RAA03867@reisser.regent.e-technik.tu-muenchen.de>
X-SW-Source: 2000-q1/msg01056.html
Content-length: 988
I have been used to issue e.g. `maint i sec'. Due to the new
`maint internal-error' command, `maint i sec' is now ambigous.
I could live with this, but as the top level `info' command can be abbreviated
via `i', GDB should be consistent and allow the same for `mt info'.
Here is a patch:
2000-03-27 Peter Schauer <pes@regent.e-technik.tu-muenchen.de>
* maint.c (_initialize_maint_cmds): Add `mt i' alias for `mt info'.
--- gdb/maint.c.orig Thu Sep 9 01:59:19 1999
+++ gdb/maint.c Sat Mar 25 20:46:19 2000
@@ -375,6 +375,7 @@ to test internal functions such as the C
"Commands for showing internal info about the program being debugged.",
&maintenanceinfolist, "maintenance info ", 0,
&maintenancelist);
+ add_alias_cmd ("i", "info", class_maintenance, 1, &maintenancelist);
add_cmd ("sections", class_maintenance, maintenance_info_sections,
"List the BFD sections of the exec and core files.",
--
Peter Schauer pes@regent.e-technik.tu-muenchen.de
From kevinb@cygnus.com Sat Apr 01 00:00:00 2000
From: Kevin Buettner <kevinb@cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Subject: [PATCH RFA] symfile.c bounds check
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <1000318223035.ZM11861@ocotillo.lan>
X-SW-Source: 2000-q1/msg00774.html
Content-length: 1202
I was seeing rather severe problems (gdb coredumps; test suite
wouldn't run at all) on linux/ppc after my recent solib.c changes.
The following patch fixes these problems. (Also, since this is happening,
MAX_SECTIONS needs to be even bigger. We probably just ought to
redesign struct section_addr_info so that it can be dynamically sized.)
May I check this in?
* symfile.c (syms_from_objfile): Added bounds check prior to
accessing ``other'' array in a section_addr_info struct.
Index: symfile.c
===================================================================
RCS file: /cvs/src/src/gdb/symfile.c,v
retrieving revision 1.2
diff -u -p -r1.2 symfile.c
--- symfile.c 2000/03/15 19:43:57 1.2
+++ symfile.c 2000/03/18 22:18:53
@@ -738,7 +790,9 @@ syms_from_objfile (objfile, addrs, mainl
else if (strcmp (s->the_bfd_section->name, ".bss") == 0)
s_addr = addrs->bss_addr;
else
- for (i = 0; !s_addr && addrs->other[i].name; i++)
+ for (i = 0;
+ !s_addr && i < MAX_SECTIONS && addrs->other[i].name;
+ i++)
if (strcmp (s->the_bfd_section->name, addrs->other[i].name) == 0)
s_addr = addrs->other[i].addr; /* end added for gdb/13815 */
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2000-04-01 0:00 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <38D6CF69.6844@cygnus.com>
[not found] ` <200003211819.NAA12435@indy.delorie.com>
[not found] ` <38D7C977.FA3@cygnus.com>
2000-03-21 11:31 ` gdb.texinfo broken? J.T. Conklin
2000-03-21 14:56 ` Andrew Cagney
2000-04-01 0:00 ` Dmitry Sivachenko
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox