From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephane Carrez To: gdb-patches@sourceware.cygnus.com Subject: path for gdb/dwarf2read.c, support 16-bit targets in dwarf-2 Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38B2F3D3.54CF0AF0@worldnet.fr> X-SW-Source: 2000-q1/msg00306.html Hi! The following patch fixes GDB dwarf-2 reader to support 16-bit address targets. In 'dwarf2_build_psymtabs_hard' there was a hack to guess the size of the target address. We were using the bfd 'elf_size_info::arch_size' member. This corresponds to the ELF file arch size, not the target address size. I suggest to use 'bfd_arch_bits_per_address' which really corresponds to what we need. Then, in 'read_address', we just have to read 2-bytes addresses. I've been using this fix for a while with the 68HC11 port. Can you integrate it? Thanks, Stephane 2000-02-22 Stephane Carrez * dwarf2read.c (dwarf2_build_psymtabs_hard): Use bfd_arch_bits_per_address to get the size of addresses. (read_address): Read 16-bits addresses. --- /src/gnu/cygnus/gdb/gdb/dwarf2read.c Tue Feb 15 21:42:05 2000 +++ gdb/dwarf2read.c Mon Feb 21 21:17:46 2000 @@ -938,7 +938,7 @@ dwarf2_build_psymtabs_hard (objfile, mai CORE_ADDR lowpc, highpc; /* Number of bytes of any addresses that are signficant */ - address_significant_size = get_elf_backend_data (abfd)->s->arch_size / 8; + address_significant_size = bfd_arch_bits_per_address (abfd) / 8; info_ptr = dwarf_info_buffer; abbrev_ptr = dwarf_abbrev_buffer; @@ -980,6 +980,7 @@ 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).", @@ -3487,6 +3488,9 @@ read_address (abfd, buf) switch (address_size) { + case 2: + retval = bfd_get_16 (abfd, (bfd_byte *) buf); + break; case 4: retval = bfd_get_32 (abfd, (bfd_byte *) buf); break; >From kettenis@wins.uva.nl Sat Apr 01 00:00:00 2000 From: Mark Kettenis To: jimb@cygnus.com Cc: gdb-patches@sourceware.cygnus.com Subject: Patch for i386-linux-nat.c Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200001292235.e0TMZNI01759@delius.kettenis.local> X-SW-Source: 2000-q1/msg00047.html Content-length: 21211 Hi Jim, Here is a patch for i386-linux-nat.c. The main reason for the patch is to change gregset_t and fpregset_t to elf_gregset_t and elf_fpregset_t. There were two different definitions of gregset_t and fpregset_t on Linux, which were quite different from each other. The next glibc (version 2.1.3) will finaly put an end to this braindamage, but this will break GDB. While hacking on the file I noticed that there were quite a number of inconsistencies in the comments and names of variables. I've gone over all the comments and rewritten most of them to describe in a more precise way what they do and to use more consistent terminology. I know gratitious reformatting is frowned upon, but I honestly think that this patch makes the file a lot easier to read. Mark PS Before christmas I sent a message about a fix to supply_fpregset to mask of the reserved bits of the FP control registers: http://sourceware.cygnus.com/ml/gdb-patches/1999-q4/msg00375.html You promised to look at it, but probably forgot about it. Of course the patch included in there interferes with the one here. I'll create a new patch when after this patch has been applied. 2000-01-29 Mark Kettenis * i386-linux-nat.c: Use elf_gregset_t and elf_fpregset_t instead of gregset_t and fpregset_t. Those are the only names that are guaranteed to specify the right types for all supported Linux systems out there. Various doc fixes and gratitious local variable renames, all in an attempt to stress similarities between the code and unify the terminology used. (regmap): Remove trailing comma. (FPREG_ADDR): Renamed from FPREGSET_T_FPREG_ADDR. (convert_to_gregset): Make static. Remove GDB_REGS argument. It is unnecessary and wasn't used anyway. All callers changed. (convert_to_fpregset, convert_to_xfpregset): Likewise. Index: gdb/i386-linux-nat.c =================================================================== RCS file: /cvs/gdb/gdb/gdb/i386-linux-nat.c,v retrieving revision 1.1.1.8 diff -u -r1.1.1.8 i386-linux-nat.c --- gdb/i386-linux-nat.c 2000/01/18 00:54:14 1.1.1.8 +++ gdb/i386-linux-nat.c 2000/01/29 22:34:40 @@ -20,7 +20,7 @@ #include "inferior.h" #include "gdbcore.h" -/* For i386_linux_skip_solib_resolver */ +/* For i386_linux_skip_solib_resolver. */ #include "symtab.h" #include "frame.h" #include "symfile.h" @@ -34,27 +34,40 @@ #include #endif -/* - * Some systems (Linux) may have threads implemented as pseudo-processes, - * in which case we may be tracing more than one process at a time. - * In that case, inferior_pid will contain the main process ID and the - * individual thread (process) id mashed together. These macros are - * used to separate them out. The definitions may be overridden in tm.h - */ +/* On Linux, threads are implemented as pseudo-processes, in which + case we may be tracing more than one process at a time. In that + case, inferior_pid will contain the main process ID and the + individual thread (process) ID mashed together. These macros are + used to separate them out. These definitions should be overridden + if thread support is included. */ #if !defined (PIDGET) /* Default definition for PIDGET/TIDGET. */ -#define PIDGET(PID) PID -#define TIDGET(PID) 0 +# define PIDGET(PID) PID +# define TIDGET(PID) 0 #endif -/* This is a duplicate of the table in i386-xdep.c. */ +/* The register sets used in Linux ELF core-dumps are identical to the + register sets in `struct user' that was used for in a.out + core-dumps, that is also used by `ptrace'. The corresponding types + are `elf_gregset_t' for the general-purpose registers (with + `elf_greg_t' the type of a single GP register) and `elf_fpregset_t' + for the floating-point registers. + + Those types used to be available under the names `gregset_t' and + `fpregset_t' too, and this file used those names in the past. But + those names are now used for the register sets used in the + `mcontext_t' type, and have a different size and layout. */ + + +/* Mapping between the general-purpose registers in `struct user' + format and GDB's register file layout. */ static int regmap[] = { EAX, ECX, EDX, EBX, UESP, EBP, ESI, EDI, EIP, EFL, CS, SS, - DS, ES, FS, GS, + DS, ES, FS, GS }; @@ -92,40 +105,31 @@ -/* Transfering the general registers between GDB, inferiors and core files. */ +/* Transfering the general-purpose registers between GDB, inferiors + and core files. */ -/* Given a pointer to a general register set in struct user format - (gregset_t *), unpack the register contents and supply them as - gdb's idea of the current register values. */ +/* Fill GDB's register file with the genereal-purpose register values + in *GREGSETP. */ void -supply_gregset (gregsetp) - gregset_t *gregsetp; +supply_gregset (elf_gregset_t *gregsetp) { - register int regi; - register greg_t *regp = (greg_t *) gregsetp; + elf_greg_t *regp = (elf_greg_t *) gregsetp; + int regi; for (regi = 0; regi < NUM_GREGS; regi++) - { - supply_register (regi, (char *) (regp + regmap[regi])); - } + supply_register (regi, (char *) (regp + regmap[regi])); } -/* Fill in a gregset_t object with selected data from a gdb-format - register file. - - GREGSETP points to the gregset_t object to be filled. - - GDB_REGS points to the GDB-style register file providing the data. - - VALID is an array indicating which registers in GDB_REGS are - valid; the parts of *GREGSETP that would hold registers marked - invalid in GDB_REGS are left unchanged. If VALID is zero, all - registers are assumed to be valid. */ -void -convert_to_gregset (gregset_t *gregsetp, - char *gdb_regs, - signed char *valid) +/* Convert the valid general-purpose register values in GDB's register + file to `struct user' format and store them in *GREGSETP. The + array VALID indicates which register values are valid. If VALID is + NULL, all registers are assumed to be valid. */ +static void +convert_to_gregset (elf_gregset_t *gregsetp, signed char *valid) { + elf_greg_t *regp = (elf_greg_t *) gregsetp; int regi; - register greg_t *regp = (greg_t *) gregsetp; for (regi = 0; regi < NUM_GREGS; regi++) if (! valid || valid[regi]) @@ -133,64 +137,70 @@ } -/* Store GDB's value for REGNO in *GREGSETP. If REGNO is -1, do all - of them. */ +/* Fill register REGNO (if it is a general-purpose register) in + *GREGSETPS with the value in GDB's register file. If REGNO is -1, + do this for all registers. */ void -fill_gregset (gregset_t *gregsetp, - int regno) +fill_gregset (elf_gregset_t *gregsetp, int regno) { if (regno == -1) - convert_to_gregset (gregsetp, registers, 0); - else if (regno >= 0 && regno < NUM_GREGS) { + convert_to_gregset (gregsetp, NULL); + return; + } + + if (GETREGS_SUPPLIES (regno)) + { signed char valid[NUM_GREGS]; + memset (valid, 0, sizeof (valid)); valid[regno] = 1; - convert_to_gregset (gregsetp, registers, valid); + + convert_to_gregset (gregsetp, valid); } } -/* Read the general registers from the process, and store them - in registers[]. */ +/* Fetch all general-purpose registers from process/thread TID and + store their values in GDB's register file. */ static void fetch_regs (int tid) { - int ret, regno; - gregset_t buf; + elf_gregset_t regs; + int ret; - ret = ptrace (PTRACE_GETREGS, tid, 0, (int) &buf); + ret = ptrace (PTRACE_GETREGS, tid, 0, (int) ®s); if (ret < 0) { - warning ("Couldn't get registers"); + warning ("Couldn't get registers."); return; } - supply_gregset (&buf); + supply_gregset (®s); } -/* Set the inferior's general registers to the values in registers[] - --- but only those registers marked as valid. */ +/* Store all valid general-purpose registers in GDB's register file + into the process/thread specified by TID. */ static void store_regs (int tid) { - int ret, regno; - gregset_t buf; + elf_gregset_t regs; + int ret; - ret = ptrace (PTRACE_GETREGS, tid, 0, (int) &buf); + ret = ptrace (PTRACE_GETREGS, tid, 0, (int) ®s); if (ret < 0) { - warning ("Couldn't get registers"); + warning ("Couldn't get registers."); return; } - convert_to_gregset (&buf, registers, register_valid); + convert_to_gregset (®s, register_valid); - ret = ptrace (PTRACE_SETREGS, tid, 0, (int)buf); + ret = ptrace (PTRACE_SETREGS, tid, 0, (int) ®s); if (ret < 0) { - warning ("Couldn't write registers"); + warning ("Couldn't write registers."); return; } } @@ -199,20 +209,19 @@ /* Transfering floating-point registers between GDB, inferiors and cores. */ -/* What is the address of st(N) within the fpregset_t structure F? */ -#define FPREGSET_T_FPREG_ADDR(f, n) \ - ((char *) &(f)->st_space + (n) * 10) +/* What is the address of st(N) within the floating-point register set F? */ +#define FPREG_ADDR(f, n) ((char *) &(f)->st_space + (n) * 10) /* Fill GDB's register file with the floating-point register values in *FPREGSETP. */ void -supply_fpregset (fpregset_t *fpregsetp) +supply_fpregset (elf_fpregset_t *fpregsetp) { - int i; + int reg; /* Supply the floating-point registers. */ - for (i = 0; i < 8; i++) - supply_register (FP0_REGNUM + i, FPREGSET_T_FPREG_ADDR (fpregsetp, i)); + for (reg = 0; reg < 8; reg++) + supply_register (FP0_REGNUM + reg, FPREG_ADDR (fpregsetp, reg)); supply_register (FCTRL_REGNUM, (char *) &fpregsetp->cwd); supply_register (FSTAT_REGNUM, (char *) &fpregsetp->swd); @@ -234,27 +243,21 @@ } -/* Fill in an fpregset_t structure with selected data from a - gdb-format register file. - - FPREGSETP points to the structure to be filled. - - GDB_REGS points to the GDB-style register file providing the data. - - VALID is an array indicating which registers in GDB_REGS are - valid; the parts of *FPREGSETP that would hold registers marked - invalid in GDB_REGS are left unchanged. If VALID is zero, all - registers are assumed to be valid. */ -void -convert_to_fpregset (fpregset_t *fpregsetp, - char *gdb_regs, - signed char *valid) +/* Convert the valid floating-point register values in GDB's register + file to `struct user' format and store them in *FPREGSETP. The + array VALID indicates which register values are valid. If VALID is + NULL, all registers are assumed to be valid. */ +static void +convert_to_fpregset (elf_fpregset_t *fpregsetp, signed char *valid) { - int i; + int reg; /* Fill in the floating-point registers. */ - for (i = 0; i < 8; i++) - if (!valid || valid[i]) - memcpy (FPREGSET_T_FPREG_ADDR (fpregsetp, i), - ®isters[REGISTER_BYTE (FP0_REGNUM + i)], - REGISTER_RAW_SIZE(FP0_REGNUM + i)); + for (reg = 0; reg < 8; reg++) + if (!valid || valid[reg]) + memcpy (FPREG_ADDR (fpregsetp, reg), + ®isters[REGISTER_BYTE (FP0_REGNUM + reg)], + REGISTER_RAW_SIZE(FP0_REGNUM + reg)); #define fill(MEMBER, REGNO) \ if (! valid || valid[(REGNO)]) \ @@ -283,68 +286,78 @@ } -/* Given a pointer to a floating point register set in (fpregset_t *) - format, update all of the registers from gdb's idea of the current - floating point register set. */ - +/* Fill register REGNO (if it is a floating-point register) in + *FPREGSETP with the value in GDB's register file. If REGNO is -1, + do this for all registers. */ void -fill_fpregset (fpregset_t *fpregsetp, - int regno) +fill_fpregset (elf_fpregset_t *fpregsetp, int regno) { - convert_to_fpregset (fpregsetp, registers, 0); + if (regno == -1) + { + convert_to_fpregset (fpregsetp, NULL); + return; + } + + if (GETFPREGS_SUPPLIES(regno)) + { + signed char valid[MAX_NUM_REGS]; + + memset (valid, 0, sizeof (valid)); + valid[regno] = 1; + + convert_to_fpregset (fpregsetp, valid); + } } -/* Get the whole floating point state of the process and store the - floating point stack into registers[]. */ +/* Fetch all floating-point registers from process/thread TID and store + thier values in GDB's register file. */ static void fetch_fpregs (int tid) { - int ret, regno; - fpregset_t buf; + elf_fpregset_t fpregs; + int ret; - ret = ptrace (PTRACE_GETFPREGS, tid, 0, (int) &buf); + ret = ptrace (PTRACE_GETFPREGS, tid, 0, (int) &fpregs); if (ret < 0) { - warning ("Couldn't get floating point status"); + warning ("Couldn't get floating point status."); return; } - /* ptrace fills an fpregset_t, so we can use the same function we do - for core files. */ - supply_fpregset (&buf); + supply_fpregset (&fpregs); } -/* Set the inferior's floating-point registers to the values in - registers[] --- but only those registers marked valid. */ +/* Store all valid floating-point registers in GDB's register file + into the process/thread specified by TID. */ static void store_fpregs (int tid) { + elf_fpregset_t fpregs; int ret; - fpregset_t buf; - ret = ptrace (PTRACE_GETFPREGS, tid, 0, (int) &buf); + ret = ptrace (PTRACE_GETFPREGS, tid, 0, (int) &fpregs); if (ret < 0) { - warning ("Couldn't get floating point status"); + warning ("Couldn't get floating point status."); return; } - convert_to_fpregset (&buf, registers, register_valid); + convert_to_fpregset (&fpregs, register_valid); - ret = ptrace (PTRACE_SETFPREGS, tid, 0, (int) &buf); + ret = ptrace (PTRACE_SETFPREGS, tid, 0, (int) &fpregs); if (ret < 0) { - warning ("Couldn't write floating point status"); + warning ("Couldn't write floating point status."); return; } } + /* Transfering floating-point and SSE registers to and from GDB. */ - /* PTRACE_GETXFPREGS is a Cygnus invention, since we wrote our own Linux kernel patch for SSE support. That patch may or may not actually make it into the official distribution. If you find that @@ -353,6 +366,9 @@ you can delete this code. */ #ifdef HAVE_PTRACE_GETXFPREGS + +/* Fill GDB's register file with the floating-point and SSE register + values in *XFPREGS. */ static void supply_xfpregset (struct user_xfpregs_struct *xfpregs) { @@ -389,9 +405,12 @@ } +/* Convert the valid floating-point and SSE registers in GDB's + register file to `struct user' format and store them in *XFPREGS. + The array VALID indicates which registers are valid. If VALID is + NULL, all registers are assumed to be valid. */ static void convert_to_xfpregset (struct user_xfpregs_struct *xfpregs, - char *gdb_regs, signed char *valid) { int reg; @@ -437,13 +456,14 @@ } -/* Make a PTRACE_GETXFPREGS request, and supply all the register - values that yields to GDB. */ +/* Fetch all registers covered by the PTRACE_SETXFPREGS request from + process/thread TID and store their values in GDB's register file. + Return non-zero if successful, zero otherwise. */ static int fetch_xfpregs (int tid) { - int ret; struct user_xfpregs_struct xfpregs; + int ret; if (! have_ptrace_getxfpregs) return 0; @@ -457,7 +477,7 @@ return 0; } - warning ("couldn't read floating-point and SSE registers."); + warning ("Couldn't read floating-point and SSE registers."); return 0; } @@ -466,13 +486,14 @@ } -/* Send all the valid register values in GDB's register file covered - by the PTRACE_SETXFPREGS request to the inferior. */ +/* Store all valid registers in GDB's register file covered by the + PTRACE_SETXFPREGS request into the process/thread specified by TID. + Return non-zero if successful, zero otherwise. */ static int store_xfpregs (int tid) { - int ret; struct user_xfpregs_struct xfpregs; + int ret; if (! have_ptrace_getxfpregs) return 0; @@ -486,11 +507,11 @@ return 0; } - warning ("couldn't read floating-point and SSE registers."); + warning ("Couldn't read floating-point and SSE registers."); return 0; } - convert_to_xfpregset (&xfpregs, registers, register_valid); + convert_to_xfpregset (&xfpregs, register_valid); if (ptrace (PTRACE_SETXFPREGS, tid, 0, &xfpregs) < 0) { @@ -530,26 +551,26 @@ #endif + /* Transferring arbitrary registers between GDB and inferior. */ - -/* Fetch registers from the child process. - Fetch all if regno == -1, otherwise fetch all ordinary - registers or all floating point registers depending - upon the value of regno. */ +/* Fetch register REGNO from the child process. If REGNO is -1, do + this for all registers (including the floating point and SSE + registers). */ void fetch_inferior_registers (int regno) { - /* linux lwp id's are process id's */ int tid; + /* Linux LWP ID's are process ID's. */ if ((tid = TIDGET (inferior_pid)) == 0) - tid = inferior_pid; /* not a threaded program */ + tid = inferior_pid; /* Not a threaded program. */ - /* Use the xfpregs requests whenever possible, since they transfer - more registers in one system call, and we'll cache the results. - But remember that fetch_xfpregs can fail, and return zero. */ + /* Use the PTRACE_GETXFPREGS request whenever possible, since it + transfers more registers in one system call, and we'll cache the + results. But remember that fetch_xfpregs can fail, and return + zero. */ if (regno == -1) { fetch_regs (tid); @@ -586,24 +607,20 @@ } -/* Store our register values back into the inferior. - If REGNO is -1, do this for all registers. - Otherwise, REGNO specifies which register, which - then determines whether we store all ordinary - registers or all of the floating point registers. */ - +/* Store register REGNO back into the child process. If REGNO is -1, + do this for all registers (including the floating point and SSE + registers). */ void -store_inferior_registers (regno) - int regno; +store_inferior_registers (int regno) { - /* linux lwp id's are process id's */ int tid; + /* Linux LWP ID's are process ID's. */ if ((tid = TIDGET (inferior_pid)) == 0) - tid = inferior_pid; /* not a threaded program */ + tid = inferior_pid; /* Not a threaded program. */ - /* Use the xfpregs requests whenever possible, since they transfer - more registers in one system call. But remember that + /* Use the PTRACE_SETXFPREGS requests whenever possibl, since it + transfers more registers in one system call. But remember that store_xfpregs can fail, and return zero. */ if (regno == -1) { @@ -626,7 +643,8 @@ return; /* Either our processor or our kernel doesn't support the SSE - registers, so just write the FP registers in the traditional way. */ + registers, so just write the FP registers in the traditional + way. */ store_fpregs (tid); return; } @@ -651,26 +669,25 @@ register contents. CORE_REG_SIZE is its size. WHICH says which register set corelow suspects this is: - 0 --- the general register set, in gregset format - 2 --- the floating-point register set, in fpregset format - 3 --- the extended floating-point register set, in struct - user_xfpregs_struct format + 0 --- the general-purpose register set, in elf_gregset_t format + 2 --- the floating-point register set, in elf_fpregset_t format + 3 --- the extended floating-point register set, in struct + user_xfpregs_struct format - DUMMY isn't used on Linux. */ + REG_ADDR isn't used on Linux. */ static void i386_linux_fetch_core_registers (char *core_reg_sect, unsigned core_reg_size, - int which, - CORE_ADDR dummy) + int which, CORE_ADDR reg_addr) { - gregset_t gregset; - fpregset_t fpregset; + elf_gregset_t gregset; + elf_fpregset_t fpregset; switch (which) { case 0: if (core_reg_size != sizeof (gregset)) - warning ("wrong size gregset struct in core file"); + warning ("Wrong size gregset in core file."); else { memcpy (&gregset, core_reg_sect, sizeof (gregset)); @@ -680,7 +697,7 @@ case 2: if (core_reg_size != sizeof (fpregset)) - warning ("wrong size fpregset struct in core file"); + warning ("Wrong size fpregset in core file."); else { memcpy (&fpregset, core_reg_sect, sizeof (fpregset)); @@ -691,9 +708,10 @@ #ifdef HAVE_PTRACE_GETXFPREGS { struct user_xfpregs_struct xfpregset; + case 3: - if (core_reg_size != sizeof (struct user_xfpregs_struct)) - warning ("wrong size user_xfpregs_struct in core file"); + if (core_reg_size != sizeof (xfpregset)) + warning ("Wrong size user_xfpregs_struct in core file."); else { memcpy (&xfpregset, core_reg_sect, sizeof (xfpregset)); @@ -720,6 +738,7 @@ i386_linux_fetch_core_registers, /* core_read_registers */ NULL /* next */ }; + /* Calling functions in shared libraries. */ >From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney To: Mark Kettenis Cc: gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH] Replace ../include/wait.h with gdb_wait.h. Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38A244B4.DF8E231C@cygnus.com> References: <38A12872.13D194C4@cygnus.com> <200002091429.e19ETk916570@delius.kettenis.local> X-SW-Source: 2000-q1/msg00108.html Content-length: 676 FYI, Mark Kettenis wrote: > There is a problem with `linux-thread.c', where `gdb_wait.h' is included > before config.h. This means that HAVE_SYS_WAIT_H and HAVE_WAIT_H are > still undefined and the system headers are never used. FYI, I've comitted just this bit. Per other e-mail, the rest will follow. Andrew > +#include "defs.h" > #include /* for pid_t */ > #include /* for PT_* flags */ > #include "gdb_wait.h" /* for WUNTRACED and __WCLONE flags */ > #include /* for struct sigaction and NSIG */ > #include > > -#include "defs.h" > #include "target.h" > #include "inferior.h" > #include "gdbcore.h" >From nsd@cygnus.com Sat Apr 01 00:00:00 2000 From: nsd@cygnus.com To: john@feith.com Cc: cgf@cygnus.com, eliz@delorie.com, gdb-patches@sourceware.cygnus.com, jimb@cygnus.com, msnyder@cygnus.com Subject: Re: GDB 4.17 Patch for stack aligned i386 code Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200003250007.AAA07650@nog.bosbc.com> References: <200003242355.SAA14221@jwlab.FEITH.COM> X-SW-Source: 2000-q1/msg01011.html Content-length: 520 >Are you handling non-leaf functions even when the stack pointer is changing? Yes. It works by emulating instructions to figure out the stack pointer on entry to or exit from the function. The opcodes library, with a few minor changes, provides the instruction information in an architecture-independent format. >Does your patch handle functions where the prologue uses "andl" to align >the frame? I don't know. Do you happen to have an example of how to generate such code? I'd be interested in trying it. Nick >From kevinb@cygnus.com Sat Apr 01 00:00:00 2000 From: Kevin Buettner To: Andrew Cagney Cc: gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH RFA] Configury changes for IA-64 Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <1000321051613.ZM20603@ocotillo.lan> References: <1000321003058.ZM20160@ocotillo.lan> <38D6FD73.AEF13B2D@cygnus.com> X-SW-Source: 2000-q1/msg00848.html Content-length: 175 On Mar 21, 3:41pm, Andrew Cagney wrote: > PS, should the configure.tgt addition appear after ``i960-*''? Right you are. I'll fix it before checking it in. Thanks, Kevin >From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney To: GDB Patches Cc: elena@cygnus.com Subject: [MAINT] Expand readline/ maintaners Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38C21E40.34CF06CB@cygnus.com> X-SW-Source: 2000-q1/msg00521.html Content-length: 1252 FYI, I've added the following. Andrew Sun Mar 5 19:40:27 2000 Andrew Cagney * MAINTAINERS (readline/): Expand to include host maintainers. Index: MAINTAINERS =================================================================== RCS file: /cvs/src/src/gdb/MAINTAINERS,v retrieving revision 1.20 diff -p -r1.20 MAINTAINERS *** MAINTAINERS 2000/03/04 06:27:00 1.20 --- MAINTAINERS 2000/03/05 08:41:50 *************** Core: Generic components used by all of *** 80,86 **** generic arch support Andrew Cagney cagney@cygnus.com target vector Andrew Cagney cagney@cygnus.com main (main.c, top.c) Elena Zannoni ezannoni@cygnus.com - readline Elena Zannoni ezannoni@cygnus.com event loop Elena Zannoni ezannoni@cygnus.com generic symtabs Jim Blandy jimb@cygnus.com dwarf readers Jim Blandy jimb@cygnus.com --- 80,85 ---- *************** mmalloc/ ALL Host maintainers *** 133,138 **** --- 132,142 ---- sim/ See sim/MAINTAINERS, co-ordinated by: Frank Ch. Eigler fche@cygnus.com + + readline/ Master version: ftp://ftp.cwru.edu/pub/bash/ + Elena Zannoni ezannoni@cygnus.com + Host maintainers (host dependant parts) + (but get your changes into the master version) >From eliz@delorie.com Sat Apr 01 00:00:00 2000 From: Eli Zaretskii To: msnyder@cygnus.com Cc: dima@Chg.RU, gdb-patches@sourceware.cygnus.com Subject: Re: typo in gdb.texinfo Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200003160953.EAA01859@indy.delorie.com> References: <200003151932.WAA39200@netserv1.chg.ru> <38CFE64A.2BBB@cygnus.com> X-SW-Source: 2000-q1/msg00735.html Content-length: 482 > I think the purpose of having GDBINIT be a variable is > because it has a different filename on windows/CYGWIN. > Isn't it called "gdb.ini" or something? AFAIK, `gdb.ini' is used in the DJGPP version only (Windows does allow leading dots in file names, but DOS doesn't), and the different name is explicitly mentioned in the manual, see the nodes "Mode Options" and "Command Files". So I don't think we need to hide this name behind a variable, at least not because of Windows. >From cgf@cygnus.com Sat Apr 01 00:00:00 2000 From: cgf@cygnus.com (Chris Faylor) To: gdb-patches@sourceware.cygnus.com Subject: Re: Add support for WinCE toolchains Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <88vbe5$4r5$1@cronkite.cygnus.com> References: <200002222350.PAA09035@elmo.cygnus.com> <38B32684.530F4F66@apple.com> <200002230024.TAA11216@envy.delorie.com> <38B32E01.34616D70@apple.com> X-SW-Source: 2000-q1/msg00319.html Content-length: 1875 In article < 38B32E01.34616D70@apple.com >, Stan Shebs wrote: >DJ Delorie wrote: >> >> > This should get a special mention in gdb/NEWS, and ideally in README >> > also; this is one of those situations where you'll be glad you >> > forestalled a slew of complaints and bug reports by documenting it >> > in several places. >> >> Is it acceptable to add notes to configure, so that if you said >> "./configure --target=arm-pe" it could print out "Note: if you wanted >> Windows CE, use arm-wince-pe instead" ? Maybe in the toplevel configure? > >My kneejerk is to be unenthusiastic, although I'm not sure why. I guess it >seems to me that notes in configure should be more about issues that are >more directly related to the configure script, while in this case (IIRC) the >differences are more in the sources. But that's a pretty weak theoretical >argument, and if the extra warning sets even one user on the path of rightness, >then it's worthwhile to add. Um. I'm working with Andrew on finalizing the wince stuff. Getting this checked into sourceware just now is premature. One reason is that it doesn't work on the ARM yet. One of the things I've done is to regularize the name of files that I used. Everything has a "wince" in it now since the WinCE version of PE is apparently non-standard. I've also moved WinCE-specific code out of the generic target files into their own files. If there is going to be a note, it should go in a top-level README. gdb doesn't currently care if the name of the target is arm-foo-wince. It's bfd that cares, I believe. Anyway, I would request that this patch be ignored for now. Andrew will handle this all in a future merge. -- cgf@cygnus.com Cygnus Solutions, a Red Hat company http://sourcware.cygnus.com/ http://www.redhat.com/ >From kettenis@wins.uva.nl Sat Apr 01 00:00:00 2000 From: Mark Kettenis To: shebs@shebs.cnchost.com Cc: 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: <200001281909.e0SJ97M18034@delius.kettenis.local> References: <200001281642.TAA04176@netserv1.chg.ru> <3891CD13.A68984BA@shebs.cnchost.com> X-SW-Source: 2000-q1/msg00045.html Content-length: 1510 Date: Fri, 28 Jan 2000 09:08:52 -0800 From: Stan Shebs (Hi everybody!) Welcome back Stan! Dmitry Sivachenko wrote: > I think we should use new features of texinfo. May be in future > versions typeseting @env and @command will differ from the > current behaviour. By the way, FreeBSD team already updated > texinfo to 4.0 in base distribution. I disagree here. We do have to worry about backward compatibility, just as we had to support K&R compilers for a long time, and just as we support many old OS versions. Certainly many GDB users would be disappointed if we trashed Linux support for any kernel older than, say, 2.2.5! Well, it's slightly more complicated than that. It is standard GNU procedure to include the info files in the distribution. So the user doesn't need makeinfo when building from an official release. It is also standard procedure to include texinfo.tex in the distribution, thus for making a printed manual an up-to-date texinfo isn't necessary either. Thus someone who isn't actively hacking on package doesn't need texinfo at all. Cygnus might do things a little different. Is GDB still distributed with texinfo included? The CVS version suggests that this is the case. Since the version in CVS is older than texinfo 4.0, using new features would not be very convenient! Maybe it is time for an upgrade? Because I think that if using new feature improves the markup we should try to use them. Mark >From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney To: Stephane Carrez Cc: gdb-patches@sourceware.cygnus.com, Jim Blandy 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: <38C225F3.9E236A55@cygnus.com> References: <38B2F3D3.54CF0AF0@worldnet.fr> <38BB5463.D6E5B75C@cygnus.com> <38C0D9D9.70987863@worldnet.fr> X-SW-Source: 2000-q1/msg00525.html Content-length: 1747 Stephane Carrez wrote: > > Hi! > > Andrew Cagney wrote: > > > > As for the change: > > > > > - address_significant_size = get_elf_backend_data (abfd)->s->arch_size / 8; > > > + address_significant_size = bfd_arch_bits_per_address (abfd) / 8; > > > > I'm not so sure. Does bfd_arch_bits_per_address() return 16 while the > > elf data arch_size indicate something else (elf32 vs elf16?) > > > > I've attatched some references to when a similar problem was discussed > > for a 64 bit target with 32 bit ELF binaries. > > > > Jim? > > > > Andrew > > > > http://sourceware.cygnus.com/ml/gdb-patches/1999-q4/msg00267.html > > http://sourceware.cygnus.com/ml/gdb-patches/1999-q4/msg00263.html > > > Yes > > It returns the value held by the cpu-* bfd_arch_info_type structure: > > return abfd->arch_info->bits_per_address; > > So, it's not related to the ELF format but really concerns the CPU address. > The mips architecture is able to return either 32 or 64 depending on > the CPU flavor. > > From: Andrew Cagney : > > Is there a way of determining if an object file is 32 or 64 bit? (eg > > elf32/elf64, aout32 vs aout64). > > Perhaphs bfd_arch_bits_per_address(ABFD) is correct? > I think it's not correct but you should rather do: > > get_elf_backend_data (abfd)->s->arch_size > > elf16 is not a good idea. I think we must not mix the size of cpu > address with the format of ELF files. The ELF file can be larger than > 64K and we might need indexes larger than 16-bit. When I say ``elf16'', I was thinking of an elf object file that has 16 bit addresses. I'm not sure what other consequences such a move would have. Is there any reason why s->arch_size isn't 16 in your case? Andrew >From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney To: Jim Blandy Cc: Stephane Carrez , 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: <38E06721.6D3A08CD@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/msg01079.html Content-length: 1991 Jim Blandy wrote: > Or maybe I'm misunderstanding things. Andrew, as the committer of > this change, can you comment? >From something in '97, I'll try :-) > Mon Dec 15 11:38:52 1997 Andrew Cagney > > * dwarf2read.c: From change proposed by Gavin Koch. > (address_significant_size): New static variable. > (dwarf2_build_psymtabs_hard): Check consistency between > `address_size' and `address_significant_size'. > (read_address): MASK out all but the significant bits, as > determined by `address_significant_size', of any addresses. > (elf-bfd.h): Include. > (dwarf2_build_psymtabs_hard): Set `address_significant_size' > according to the arch_size of the elf object file. I believe it is for an embedded 64 bit mips target (o64?) that is using 64 bit addresses within an elf32 executable. (but the addresses are assumed to be 32bit sign extended). Due to elf32, some debug info is 64 bits, but other (symbol table?) is only 32 bits. The mask has two effects: o it makes data from the two tables match. o it gives the user a better experience: (gdb) x/i 0x800000200 0x800000200 : ldi $1, 0 (gdb) print &start $1 = 0x800000200 vs x/i 0xffffffff800000200 0xffffffff800000200 : ldi $1, 0 (gdb) print &start $2 = 0xffffffff800000200 at the cost of carrying around wrong information and complicating the target. As for ``fixing'' it. One part is deprecating that object file format and changing it to elf64. I believe that, at the time the above format was created, BFD didn't support elf64. Also on the list is getting GDB to provide the above experience without having the internal structures lie (ie have symtab contain correct information). This is likely to be important any way as people are starting to work on the problem of a single GDB being able to debug both elf32 and elf64 binaries. I think I've got this right :-/ Andrew >From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney To: GDB Patches Subject: GDB 5 2000-03-29 Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38E17D2C.F7EB65B9@cygnus.com> X-SW-Source: 2000-q1/msg01102.html Content-length: 6421 Below is my updated TODO list for GDB 5. I've also attatched the patch I'm applying to TODO. You can see the gory details in the sources. Looking at it. There are four ``must haves'' left. For the watchpoint patches, if at least some have been addressed, I'd like to put the rest off. For Solaris/x86, what shape is it in? The remainder look like must fix bugs. Andrew GDB 5.0: Must have ------------------ These are things that have been identifed as must-have for this release of GDB. -- Watch point related patches (Eli Zaretskii, Michael Snyder, ???) Eli writes: This doesn't include the watchpoint-related patches I sent beginning with August or September, and mentioned them again three weeks ago. Here again are the pointers to the relevant messages: Hardware breakpoints and watchpoints: patches http://sourceware.cygnus.com/ml/gdb-patches/1999-q3/msg00173.html Re: Hardware breakpoints and watchpoints: patches http://sourceware.cygnus.com/ml/gdb-patches/1999-q3/msg00204.html Re: Hardware breakpoints and watchpoints: patches http://sourceware.cygnus.com/ml/gdb-patches/1999-q4/msg00200.html Hardware watchpoints for bitfields http://sourceware.cygnus.com/ml/gdb-patches/1999-q4/msg00201.html -- Tom's speedups to GDB (Tom Tromey, Jim Blandy) I believe that there was a late breaking fix that stopped a coredump. http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00869.html -- Solaris/x86 - which? (Nick Duffek, Peter Schauer, Michael Snyder?) Nick D's working through patches from Michael Snyder and Peter S. -- RFA: procfs.c: init_procfs_ops should set procfs_ops.to_has_[all]_memory (Peter Schauer, Andrew Cagney?) I am pretty sure that this is caused by some accidental deletion, but procfs.c:init_procfs_ops no longer sets procfs_ops.to_has_memory and procfs_ops.to_has_all_memory. http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg01057.html Wed Mar 29 13:40:40 2000 Andrew Cagney * TODO: Update GDB 5 status. Index: TODO =================================================================== RCS file: /cvs/src/src/gdb/TODO,v retrieving revision 1.2 diff -u -r1.2 TODO --- TODO 2000/03/27 10:24:58 1.2 +++ TODO 2000/03/29 03:43:21 @@ -62,26 +62,18 @@ -- -Texinfo broken/builds (Andrew Cagney, Stan Shebs) -Cagney probably botched a fix to a botch. +RFA: procfs.c: init_procfs_ops should set +procfs_ops.to_has_[all]_memory (Peter Schauer, Andrew Cagney?) --- +I am pretty sure that this is caused by some accidental deletion, but +procfs.c:init_procfs_ops no longer sets procfs_ops.to_has_memory and +procfs_ops.to_has_all_memory. -x86 linux GDB and SIGALRM - http://sourceware.cygnus.com/ml/gdb/2000-q1/msg00803.html + http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg01057.html -- -RFA: breakpoint.c: Minor output fixes for hardware watchpoints - http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00558.html - -During implementation of hardware watchpoints on Solaris, I noticed the -following inconsistencies in breakpoint.c output between software and -hardware breakpoints. - --- - GDB 5.0: Nice to have --------------------- @@ -126,6 +118,12 @@ The pascal support patches nave been added to the patch data base. I [cagney] strongly suspect that they are better suited for 5.1. +Indent -gnu ? + http://sourceware.cygnus.com/ml/gdb/2000-q1/msg00496.html + +2 pascal language patches inserted in database + http://sourceware.cygnus.com/ml/gdb/2000-q1/msg00521.html + -- Programs run under GDB have SIGCHLD masked. @@ -198,6 +196,39 @@ -- +x86 linux GDB and SIGALRM (???) + http://sourceware.cygnus.com/ml/gdb/2000-q1/msg00803.html + +-- + +Migrate qfThreadInfo packet -> qThreadInfo. (Andrew Cagney) + +Add support for packet enable/disable commands with these thread +packets. General cleanup. + +[PATCH] Document the ThreadInfo remote protocol queries + http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00832.html + +[PATCH] "info threads" queries for remote.c + http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00831.html + +-- + +MI documentation in GDB user guide. (Andrew Cagney, Elena Zannoni, +Stan Shebs, anyone else?) + +> (Are there plans to make gdbmi.texi be part of the manual as well?) + +I'd like to see it go in there sooner rather than later too. Otherwise +you're introducing discrepancies between the manual and the documentation, +and everybody is confused - witness the lack of doc for the tracing +commands still, some two years after they were added... + +[PATCH] GDB command-line switches and annotations docs + http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00639.html + +-- + GDB 5.0: Won't have ------------------- @@ -232,6 +263,33 @@ -- +Elimination of make_cleanup_func. (Andrew Cagney) + +make_cleanup_func elimination + http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00791.html + http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00814.html + +-- + +Allow GDB to use installed regex. Think about updating regex to more +recent version (Andrew Cagney). + +Re: A new patch for regex + http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00635.html + +A patch for gnu-regex + http://sourceware.cygnus.com/ml/gdb/2000-q1/msg00568.html + +-- + +ChangeLog.mi vs ChangeLog-mi (Andrew Cagney) +Needs further debate. + +Re: [PATCH] Add change-log variables to more MI files + http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00811.html + +-- + GDB 5.0: Test results --------------------- @@ -329,6 +387,30 @@ General Wish List ================= + +-- + +GDBARCH cleanup (Andrew Cagney) + +The non-generated parts of gdbarch.{sh,h,c} should be separated out +into gdbarch-utils.[hc] (Name ok). + +The ``info architecture'' command should be replaced with a fixed +``set architecture'' (implemented using the command.c enum code). + +Document that gdbarch_init_ftype could easily fail because it didn't +identify an architecture. + +-- + +Check that GDB can handle all BFD architectures (Andrew Cagney) + +There should be a test that checks that BFD/GDB are in sync with +regard to architecture changes. Something like a test that first +queries GDB for all supported architectures and then feeds each back +to GDB.. Anyone interested in learning how to write tests? :-) + +-- This list is probably not up to date, and opinions vary about the importance or even desirability of some of the items. >From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney To: GDB Discussion , GDB Patches Subject: Re: [MAINT] src/mmalloc maintainers Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38B9BF29.19152928@cygnus.com> References: <38B35300.41508CB6@cygnus.com> X-SW-Source: 2000-q1/msg00388.html Content-length: 4258 Andrew Cagney wrote: > > Hello, > > This directory is probably best described as one of GDB's forgotten > siblings. At present it isn't clear what the maintenance policy is. > With that in mind I'd like to propose: > > GDB's host/native maintainers have implicit check-in > rights to the src/mmalloc tree. If there isn't a > relevant host/native maintainer than the head maintainer > ends up with the problem :-) > > I can't see anyone doing anything to that directory tree unless they are > a native/host maintainer and then the only thing would be fixing > configury problems. > > I'm almost tempted to include target maintainers. I suspect, however, > that getting the native expert a chance to look things over would be > safer. > > thoughts? FYI, I've checked in the attatched. It hopefully reflects this proposal. Andrew Index: gdb/ChangeLog Mon Feb 28 10:58:45 2000 Andrew Cagney * MAINTAINERS: Mention mmalloc. Expand Host/Native and Target/Architecture maintainers descriptions. Index: mmalloc/ChangeLog Mon Feb 28 10:33:51 2000 Andrew Cagney * MAINTAINERS: New file. Index: gdb/MAINTAINERS =================================================================== RCS file: /cvs/src/src/gdb/MAINTAINERS,v retrieving revision 1.11 diff -p -r1.11 MAINTAINERS *** MAINTAINERS 2000/02/26 06:20:56 1.11 --- MAINTAINERS 2000/02/28 00:06:00 *************** available to step in if the first mainta *** 21,29 **** reason. ! Target/Architecture: Generic ISA - Instruction Set Architecture - ! issues. API variants, CPU variants. *-tdep.c. d10v target Andrew Cagney cagney@cygnus.com d30v target Andrew Cagney cagney@cygnus.com mips target Andrew Cagney cagney@cygnus.com --- 21,32 ---- reason. ! Target/Architecture: + Generic ISA (Instruction Set Architecture) issues, API variants, CPU + variants. *-tdep.c. The Target/Architecture maintainer works with the + host maintainer when resolving build issues. + d10v target Andrew Cagney cagney@cygnus.com d30v target Andrew Cagney cagney@cygnus.com mips target Andrew Cagney cagney@cygnus.com *************** arm target Fernando Nasser fnasser@cyg *** 36,47 **** m32r target Michael Snyder msnyder@cygnus.com IA-64 target Kevin Buettner kevinb@cygnus.com ! Host/Native: Target specific native support - typically shared ! libraries and quirks to procfs/ptrace/... A native maintainer works ! with the arch and core maintainer when resolving more generic ! problems. hp testsuite (gdb.hp) Jimmy Guo adl-debugger-wdb-merge-guru@cup.hp.com djgpp native Eli Zaretskii eliz@gnu.org DJ Delorie dj@cygnus.com --- 39,55 ---- m32r target Michael Snyder msnyder@cygnus.com IA-64 target Kevin Buettner kevinb@cygnus.com + + Host/Native: ! The Native maintainer is responsible for target specific ! native support - typically shared libraries and quirks to ! procfs/ptrace/... The Native maintainer works with the Arch and Core ! maintainers when resolving more generic problems. + The host maintainer ensures that gdb (including mmalloc) can be built + as a cross debugger on their platform. + hp testsuite (gdb.hp) Jimmy Guo adl-debugger-wdb-merge-guru@cup.hp.com djgpp native Eli Zaretskii eliz@gnu.org DJ Delorie dj@cygnus.com *************** Misc: *** 105,111 **** Web pages. Jim Kingdon kingdon@redhat.com (anyone can edit; kingdon is just lead maintainer) Makefile.in, configure* ALL ! Write After Approval --- 113,119 ---- Web pages. Jim Kingdon kingdon@redhat.com (anyone can edit; kingdon is just lead maintainer) Makefile.in, configure* ALL ! mmalloc ALL Host maintainers Write After Approval Index: mmalloc/MAINTAINERS =================================================================== RCS file: MAINTAINERS diff -N MAINTAINERS *** /dev/null Tue May 5 13:32:27 1998 --- MAINTAINERS Sun Feb 27 16:06:09 2000 *************** *** 0 **** --- 1,5 ---- + The mmalloc directory is maintained by the GDB group's Host + maintainers. + + This code is in a maintain-only phase - only configury patches fixing + host compile problems are generally accepted. >From msnyder@cygnus.com Sat Apr 01 00:00:00 2000 From: Michael Snyder To: Scott Bambrough Cc: Fernando Nasser , Kevin Buettner , gdb-patches@sourceware.cygnus.com Subject: Re: store_floating() and arm-tdep.c Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38C7F23D.61AF@cygnus.com> References: <1000229000345.ZM15006@ocotillo.lan> <38BCE46B.CD7889B5@cygnus.com> <1000302074643.ZM19182@ocotillo.lan> <38C7BF53.731F8CF6@redhat.com> <38C7C9A4.3566EC87@netwinder.org> X-SW-Source: 2000-q1/msg00630.html Content-length: 986 Scott Bambrough wrote: > > Fernando Nasser wrote: > > > Now that Kevin fixed store_floating() we can use it in arm-tdep.c (as > > well as extract_floating). The code in there works fine for remote > > targets but Scott has reported it fails for native Linux-ARM. > > I'll be looking into this today. Don't worry about it. > > > P.S.: I can run the test on remote ARM targets. I will need someone to > > volunteer running the tests on native as well? Scott, I guess you are > > the most appropriate "volunteer" :-) > > I've been running tests on the ARM Linux target on a NetWinder regularly. The > results of the testsuite follow. Most of the problems are due to no > linuxthreads support and problems stepping in/out or backtracing in signal > handlers. I'll work at implementing support for these over time. I was hoping > to port the x86 work, but just haven't had the time. Hmm, the new thread_db module should be pretty target-independent (correct me if I'm wrong). >From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney To: GDB Discussion , GDB Patches Subject: [GDB-MAINT] Updated maintainer list Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38A3A58E.CDB11CE9@cygnus.com> X-SW-Source: 2000-q1/msg00122.html Content-length: 3448 Hello maintainers, Below is the current list of maintainers. As such, you will all be getting check-in rights (adminstration and time permitting). Given the move to a public CVS repository now is probably a good time to review your current maintenance responsibilities and decide if you wish to continue them. I'm not trying to scare you or anything :-) It's just that this really is a big and dramatic change. d10v target Andrew Cagney cagney at cygnus dot com d30v target Andrew Cagney cagney at cygnus dot com mips target Andrew Cagney cagney at cygnus dot com mn10300 target Andrew Cagney cagney at cygnus dot com powerpc target Elena Zannoni ezannoni at cygnus dot com arm target Jim Ingham jingham at cygnus dot com m32r target Michael Snyder msnyder at cygnus dot com hp testsuite (gdb.hp) Jimmy Guo adl-debugger-wdb-merge-guru at cup dot hp dot com djgpp native DJ Delorie dj at cygnus dot com win32 host & native Chris Faylor cgf at cygnus dot com x86 linux native Jim Blandy jimb at cygnus dot com hurd native Mark Kettenis kettenis at wins.va.nl macos host & native Stan Shebs shebs at apple dot com hpux, hp pa native Jeff Law law at cygnus dot com generic arch support Andrew Cagney cagney at cygnus dot com target vector Andrew Cagney cagney at cygnus dot com main (main.c, top.c) Elena Zannoni ezannoni at cygnus dot com readline Elena Zannoni ezannoni at cygnus dot com generic symtabs Jim Blandy jimb at cygnus dot com dwarf readers Jim Blandy jimb at cygnus dot com elf reader Jim Blandy jimb at cygnus dot com stabs reader Jim Blandy jimb at cygnus dot com tracing Michael Snyder msnyder at cygnus dot com threads Michael Snyder msnyder at cygnus dot com breakpoint.c Michael Snyder msnyder at cygnus dot com language support David Taylor taylor at cygnus dot com expression eval David Taylor taylor at cygnus dot com defs.h David Taylor taylor at cygnus dot com utils.c David Taylor taylor at cygnus dot com Scheme support Jim Blandy jimb at cygnus dot com svr4 shlibs (solib.c) Jim Blandy jimb at cygnus dot com coff reader Philippe De Muyter phdm at macqel dot be remote.c Andrew Cagney cagney at cygnus dot com sds protocol Stan Shebs shebs at apple dot com rdi/adp protocol Stan Shebs shebs at apple dot com gdbserver Stan Shebs shebs at apple dot com documentation Stan Shebs shebs at apple dot com testsuite Stan Shebs shebs at apple dot com command interpreter Fernando Nasser fnasser at cygnus dot com gdbtk (c & tcl) Jim Ingham jingham at cygnus dot com libgui (w/foundry, sn) Jim Ingham jingham at cygnus dot com For what its worth, I've already received recommendations that: djgpp responsibility be transfered to Eli Zaretskii. (Eli, I assume this is ok with you. You were presented with glowing references :-) GNU/Linux/PPC responsibility go to Kevin Buettner. Given Kevin's currently frantically trying to get that code merged in I can't see any problems. (actually, all I can see are benefits :-). powerpc target be transfered to Kevin Buettner. Here it's Elena Zannoni, the current maintainer looking to pass on the reins. I can't see problems as Kevin is already knee deep in the AIX ABI code that is just one of the three ABI's burried in rs6000-tdep.c. I personaly would like to ask J.T. Conklin (jtc at redback dot com) to step forward and (at least) accept check-in after aproval rights. enjoy, Andrew >From dima@Chg.RU Sat Apr 01 00:00:00 2000 From: Dmitry Sivachenko To: gdb-patches@sourceware.cygnus.com Subject: small patch to gdb.texinfo Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200001301823.VAA60148@netserv1.chg.ru> X-SW-Source: 2000-q1/msg00051.html Content-length: 5976 Hello again! (I really don't what to spam your mailing list :) This new small patch to revision 1.1.1.14 of gdb.texinfo, cosmetic changes only. Please apply it. Thank you in advance, --dima PS: I don't sure about mapped symbol file name, please check it, I have no support of it on my FreeBSD box... --- gdb.texinfo.orig Sun Jan 30 21:01:45 2000 +++ gdb.texinfo Sun Jan 30 21:06:00 2000 @@ -225,9 +225,9 @@ from anyone else. @node Contributors -@unnumberedsec Contributors to GDB +@unnumberedsec Contributors to @value{GDBN} -Richard Stallman was the original author of GDB, and of many other +Richard Stallman was the original author of @value{GDBN}, and of many other @sc{gnu} programs. Many others have contributed to its development. This section attempts to credit major contributors. One of the virtues of free software is that everyone is free to contribute to it; with @@ -258,7 +258,7 @@ Richard Stallman, assisted at various times by Peter TerMaat, Chris Hanson, and Richard Mlynarik, handled releases through 2.8. -Michael Tiemann is the author of most of the @sc{gnu} C++ support in GDB, +Michael Tiemann is the author of most of the @sc{gnu} C++ support in @value{GDBN}, with significant additional contributions from Per Bothner. James Clark wrote the @sc{gnu} C++ demangler. Early work on C++ was by Peter TerMaat (who also did much general update work leading to release 3.0). @@ -325,7 +325,7 @@ Matsushita sponsored the support for the MN10200 and MN10300 processors. -Fujitsu sponsored the support for SPARClite and FR30 processors +Fujitsu sponsored the support for SPARClite and FR30 processors. Kung Hsu, Jeff Law, and Rick Sladkey added support for hardware watchpoints. @@ -335,7 +335,7 @@ Stu Grossman wrote gdbserver. Jim Kingdon, Peter Schauer, Ian Taylor, and Stu Grossman made -nearly innumerable bug fixes and cleanups throughout GDB. +nearly innumerable bug fixes and cleanups throughout @value{GDBN}. The following people at the Hewlett-Packard Company contributed support for the PA-RISC 2.0 architecture, HP-UX 10.20, 10.30, and 11.0 @@ -345,8 +345,8 @@ Rehrauer, and Elena Zannoni. Kim Haase provided HP-specific information in this manual. -Cygnus Solutions has sponsored GDB maintenance and much of its -development since 1991. Cygnus engineers who have worked on GDB +Cygnus Solutions has sponsored @value{GDBN} maintenance and much of its +development since 1991. Cygnus engineers who have worked on @value{GDBN} fulltime include Mark Alexander, Jim Blandy, Per Bothner, Kevin Buettner, Edith Epstein, Chris Faylor, Fred Fish, Martin Hunt, Jim Ingham, John Gilmore, Stu Grossman, Kung Hsu, Jim Kingdon, John Metzler, @@ -695,7 +695,7 @@ ``process'', and there is often no way to get a core dump. @value{GDBN} will warn you if it is unable to attach or to read core dumps. -You can run @code{gdb} without printing the front material, which describes +You can run @code{@value{GDBP}} without printing the front material, which describes @value{GDBN}'s non-warranty, by specifying @code{-silent}: @smallexample @@ -789,7 +789,7 @@ system call, you can use this option to have @value{GDBN} write the symbols from your program into a reusable file in the current directory. If the program you are debugging is -called @file{/tmp/fred}, the mapped symbol file is @file{./fred.syms}. +called @file{/tmp/fred}, the mapped symbol file is @file{/tmp/fred.syms}. Future @value{GDBN} debugging sessions notice the presence of this file, and can quickly map in symbol information from it, rather than reading the symbol table from the executable program. @@ -859,7 +859,7 @@ @item -nowindows @itemx -nw ``No windows''. If @value{GDBN} comes with a graphical user interface -(GUI) built in, then this option tells GDB to only use the command-line +(GUI) built in, then this option tells @value{GDBN} to only use the command-line interface. If no GUI is available, this option has no effect. @item -windows @@ -916,7 +916,7 @@ @table @code @kindex quit @r{[}@var{expression}@r{]} @kindex q -@item quit +@item quit @r{[}@var{expression}@r{]} To exit @value{GDBN}, use the @code{quit} command (abbreviated @code{q}), or type an end-of-file character (usually @kbd{C-d}). If you do not supply @var{expression}, @value{GDBN} will terminate normally; otherwise it will @@ -986,7 +986,7 @@ arguments whose meaning depends on the command name. For example, the command @code{step} accepts an argument which is the number of times to step, as in @samp{step 5}. You can also use the @code{step} command -with no arguments. Some command names do not allow any arguments. +with no arguments. Some commands do not allow any arguments. @cindex abbreviation @value{GDBN} command names may always be truncated if that abbreviation is @@ -1000,7 +1000,7 @@ @cindex repeating commands @kindex RET A blank line as input to @value{GDBN} (typing just @key{RET}) means to -repeat the previous command. Certain commands (for example, @code{run}) +repeat the previous command. Certain commands (for example, @code{run}) will not repeat this way; these are commands whose unintentional repetition might cause trouble and which you are unlikely to want to repeat. @@ -1289,7 +1289,7 @@ version of @value{GDBN} you are running; as @value{GDBN} evolves, new commands are introduced, and old ones may wither away. Also, many system vendors ship variant versions of @value{GDBN}, and there are -variant versions of @value{GDBN} in GNU/Linux distributions as well. +variant versions of @value{GDBN} in @sc{gnu}/Linux distributions as well. The version number is the same as the one announced when you start @value{GDBN}. @@ -1300,7 +1300,7 @@ @kindex show warranty @item show warranty Display the @sc{gnu} ``NO WARRANTY'' statement, or a warranty, -if your version of @value{GDB} comes with one. +if your version of @value{GDBN} comes with one. @end table >From ezannoni@cygnus.com Sat Apr 01 00:00:00 2000 From: Elena Zannoni To: Fernando Nasser Cc: David Whedon , gdb-patches@sourceware.cygnus.com Subject: Re: [REPOST #2] patch: command deprecator Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <14554.39919.562287.915864@kwikemart.cygnus.com> References: <38DA9AE8.64AF8635@cygnus.com> X-SW-Source: 2000-q1/msg00951.html Content-length: 432 Fernando Nasser writes: > Andrew, > > I know that there are 3 new functions (and one test proc) in David's patch and it represents an added functionality, but > the changes are not so big. Is there any chance that we could safely include those without his assignment? > > David: Maybe you got it (the assignment to FSF) already? > I saw David's name in the last assignments mail form the FSF. So he's all set. Elena