Where did my patch go?

Where did my patch go?

[Andrew Cagney]

Hello,

Attatched is a complete list of older e-mail from my GDB-patches mail
folder.  Some of these are mine but some are not.  If you can see your
patch in this list then it means that I've not forgotten you.

	Andrew
16bit-testsuite:Subject: RFA: Adapt testsuite for use with 16-bit hosts
N_MAIN:Subject: Patch: handle N_MAIN stab
Winit-Xread.c:Subject: [rfa] *read.c -Wuninitialized fixes
Winit-f-exp:Subject: [rfa/rfc] f-exp.y -Wuninitialized fixes
Winit-symfile:Subject: [rfa] symfile.c - fix apparently uninitialized my_cleanups
Winit-valops:Subject: [rfa] valops.c - simplify hand_function_call's push struct logic
Wmisc-remote:Subject: gdb under solaris7
adj-bp-addr:Subject: [PATCH RFA] TARGET_ADJUST_BREAKPOINT_ADDRESS...
alloca:Subject: [RFA] Move alloca(0) to wait_for_inferior() from registers_changed()
alpha:Subject: Patch to fix cross-debugging of x86 targets on 64-bit hosts
alpha:Subject: [PATCH]: (alpha) heuristic_proc_start
alpha:Subject: [RFA]: alpha-tdep.c
alpha:Subject: [RFA]: alpha-tdep.c/heuristic_fencepost_start
alpha:Subject: [RFA]: alpha_frame_saved_pc
alpha:Subject: [RFA]: opcodes alpha disassembler
alpha:Subject: various Alpha patches
annotate-prompt:Subject: [PATCH] top.c --annotate=2 and prompt stack
arm-fp-regnum:Subject: ARM frame fp is not always FP_REGNUM
arm-fp-regnum:Subject: ARM frame fp is not always FP_REGNUM 
auto-solib-again:Subject: [PATCH] Fix auto-solib-add bug (patch revised again)
basereg-address:Subject: [RFA] new BASEREG_ADDRESS macro
bcache-cleanup:Subject: [RFA]: Small bcache hashing cleanup
breakpoints:Subject: Bogus code in breakpoint.c
breakpoints:Subject: RFD: infrun.c:  No bpstat_stop_status call after proceed over break ?
breakpoints:Subject: [RFA] Fix for breakpoints in dynamically loaded libs
breakpoints:Subject: minor fix for i386v-nat.c
coff-solib:Subject: [patch] make coff-solib.c compile
cris:Subject: New port: CRIS architecture
dejagnu:Subject: Patch for DejaGnu test case "pointers"
dejagnu:Subject: [PATCH] dejagnu lib/framework.exp
dejagnu:Subject: [PATCH] dejagnu lib/framework.exp PRMS pattern
dejagnu:Subject: [PATCH] dejagnu lib/target.exp env cleanup
dejagnu:Subject: [PATCH] dejagnu runtest.exp
dejagnu:Subject: [PATCH] dejagnu runtest.exp cleanup
dejagnu:Subject: [PATCH] dejagnu runtest.exp misc. fixes
dejagnu:Subject: [PATCH] gdb.c++/classes.exp
dejagnu:Subject: [RFA] dejagnu runtest.exp *dir_to_run
dejagnu:Subject: [RFA] dejagnu runtest.exp redundant testing
dejagnu:Subject: [RFA] new patch: dejagnu runtest.exp redundant testing
dejagnu:Subject: [RFA] new patch: dejagnu runtest.exp redundant testing 
dejagnu:Subject: [patch] remove gdb.hp/gdb.aCC/namespace.exp test
dejagnu:Subject: recent dejagnu changes
digital-unix:Subject: On Digital UNIX, "continue" doesn't continue correctly if a signal is
digital-unix:Subject: Patch to make top-of-tree GDB compile on Digital UNIX
digital-unix:Subject: [RFD] objfiles.h, symfile.c, mdebugread.c:  Fixes for Digital Unix.
doc:Subject: Update config.guess, config.sub, texinfo.tex
doc:Subject: [RFA] Update REG_STRUCT_HAS_ADDR doco
doc:Subject: [rfc/rfa] multi-arch *_REG_TO_REGNUM()
doc:Subject: [rfc] SKIP_PROLOG_FRAMELESS_P -> PROLOG_FRAMELES_P multi-arch 
doc:Subject: patch for refcard.tex
dwarf2read:Subject: [Fwd: [RFA]: Add support for .debug_loc to dwarf2 reader]
dwarf2read:Subject: [PATCH RFA] DWARF v2.1 64-bit support
dwarf2read:Subject: [PATCH RFA] dwarf2read.c: symbol relocation in new_symbol()
dwarf2read:Subject: [PATCH] Remove all duplicate debug info for DWARF2
dwarf2read:Subject: [RFA] Reduce memory usage for dwarf2 dramatically, unify hash
dwarf2read:Subject: [rfa/symtab] Sign extend dwarf2 addresses (sometimes)
gdbserv-confg:Subject: disable gdbserver for cross builds
gdbserv-confg:Subject: gdbserver and gdb/config/nm-empty.h
gdbserver-regs-if:Subject: [PATCH]: some gdbserver changes for NetBSD/powerpc
global-gdbinit:Subject: [prelim patch] Add the notion of a global init file to gdb.
grep-func:Subject: [RFA]: Repost of grep ^func patch
grep-func:Subject: [RFA]: Repost of grep ^func patch 
h8300:Subject: [Fwd: [new file] gdb/testsuite/gdb.disasm/h8300s.exp]
h8300:Subject: [new file] gdb/testsuite/gdb.disasm/h8300s.exp
h8:Subject: Hatachi h8300 and h8500?
hpux:Subject: GDB 5.0: Errors building on HPUX 10.01
hpux:Subject: HP-UX 11.00?
hpux:Subject: RFC: patch to allow building on HPUX 11
hpux:Subject: [PATCH] som_solib_add_solib_objfile
hpux:Subject: problem with gdb-5.0 on hpux-11.00 64bit
inf-is32k:Subject: RFA: Patch to ser-unix.c (When infinite equals 32K seconds)
infrun-proceed:Subject: [RFA]: infrun.c/proceed change
irix:Subject: Fix Irix core dumps
irix:Subject: [2nd RFA] Make core dumps work on Irix
java:Subject: [RFA]: Java baseclass offset patch (Was Re: question about gdb)
java:Subject: [RFA]: Java baseclass offset patch (Was question about gdb)
klm:Subject: [Patch] option -noreloc in add-symbol-file (linux module debugging)
maint:Subject: General check in rights ...
maint:Subject: HP maintainers 
maint:Subject: [PATCH]demangle.c
maint:Subject: gdb under solaris7
maint:Subject: patch for ARM GNU/Linux
maint:Subject: patch for ARM GNU/Linux 
mips-decode:Subject: gdb 5.0: mips-tdep.c (mips32_next_pc): branches get misdecoded
mips-sim:Subject: RFA: Recording MIPS ABI selection in binaries
mips-sim:Subject: RFA: Recording MIPS ABI selection in binaries 
mips-sim:Subject: [patch] Add start of mips32/mips64 support to sim/mips/mips.igen
mips-sim:Subject: [patch] sim/mips/mips.igen: fix some trivial bugs
mips-sim:Subject: [patch] sim/mips/mips.igen: make some insn encodings look more std.
mips-sim:Subject: [patch] sim/mips/mips.igen: make use of model names consistent.
mips-sim:Subject: patch: sim/mips/mips.igen: check use of 64-bit insns, fix tracing.
mips-sim:Subject: sim/igen: add gen-delay-slot generation option
mips64-config:Subject: [RFA] make mips64_transfers_32bit_regs_p configurable
misc:Subject: RFA: Remove unused synchronous code
misc:Subject: [Fwd: core-ena.c and multi-arch]
misc:Subject: [PATCH] GDB friendly assert
misc:Subject: [rfa] Change line to long
misc:Subject: [rfa] Hack around coffread cast ...
misc:Subject: core-ena.c and multi-arch
misc:Subject: small enhancements to gdb here..
monitor-regexp:Subject: [RFA]: Use regexp to check result of write reg/memory in monitors
multi-arch:Subject: Fwd: TM_PRINT_INSN_MACH needs to be in gdbarch struct
multi-arch:Subject: SIGTRAMP_START, IN_SIGTRAMP, SIGTRAMP_END
multi-arch:Subject: TM_PRINT_INSN_MACH needs to be in gdbarch struct
multi-arch:Subject: multi-arch: CANNOT_STEP_HW_WATCHPOINTS
multi-arch:Subject: multi-arch: HAVE_CONTINUABLE_WATCHPOINT
multi-arch:Subject: multi-arch: HAVE_NONSTEPPABLE_WATCHPOINT
multi-arch:Subject: multi-arch: HAVE_STEPPABLE_WATCHPOINT
multi-arch:Subject: multi-arch: STOPPED_BY_WATCHPOINT
multi-arch:Subject: multi-arch: TARGET_CAN_USE_HARDWARE_WATCHPOINT
multi-arch:Subject: multi-arch: TARGET_DISABLE_HW_WATCHPOINTS
multi-arch:Subject: multi-arch: TARGET_HAS_HARDWARE_WATCHPOINTS
multi-arch:Subject: multi-arch: TARGET_RANGE_PROFITABLE_FOR_HW_WATCHPOINT
multi-arch:Subject: multi-arch: target_insert_watchpoint
multi-arch:Subject: multi_arch: TARGET_ENABLE_HW_WATCHPOINTS
multi-arch:Subject: multi_arch: target_remove_watchpoint
nexti:Subject: RFA: [infrun.c] Fix to "nexti".
nexti:Subject: [Fwd: RFA: [infrun.c] Fix to "nexti".]
pascal:Subject: 2nd try [PATCH RFA] Pascal language part 3:
pascal:Subject: 2nd try [PATCH RFA] Pascal language part 3: Changes
pascal:Subject: 2nd try [PATCH RFA] Pascal language part 3: Changes to
pascal:Subject: Pascal language Makefile.in patch still pending.
pascal:Subject: TODO and NEWS changes for pascal language.
pascal:Subject: [PATCH RFA] Pascal language part 2.
pascal:Subject: [PATCH RFA] Pascal language part 3: Changes to Makefile.in
pascal:Subject: [PATCH RFC] Problem with pascal objects.
pascal:Subject: [PATCH RFC] pascal pointer type names
pointers-fp:Subject: Patch for DejaGnu test case "pointers"
pseudo-size:Subject: [PATCH]: Fixes for pseudo regs support
readline:Subject: input grabbing in RL callback
reg-sideeffects:Subject: RFA [eval.c]: Fix handling of registers when EVAL_AVOID_SIDE_EFFECTS
regcache-h:Subject: Register Cache.
regcache-h:Subject: [PATCH] The birth of regcache.h
regcache-h:Subject: regcache.c/regcache.h
register-bytes:Subject: [RFA] gdbarch.sh: document REGISTER_SIZE and REGISTER_BYTES
s390:Subject:  S390 gdb patches
s390:Subject:  SSH access; Was: S390 gdb patches
s390:Subject: S390 gdb patches
s390:Subject: SSH access; Was: S390 gdb patches
s390:Subject: Stuff which I think which still needs to be dealt with in
s390:Subject: What is copyright status of some gdb files ?
solib:Subject: [RFC] WIP: Implement auto-solib-add for AIX
solib:Subject: gdb 5.0: solib.c (LM_ADDR) should be signed, not unsigned
solib:Subject: gdb 5.0: solib.c (LM_ADDR) should be signed, not unsigned (fwd)
solib:Subject: gdb 5.0: solib.c: LM_ADDR is treated as a memory address
solib:Subject: gdb 5.0: solib.c: LM_ADDR is treated as a memory address (fwd)
sparc:Subject: Fw: GDB 5.0 won't build on GNU/Linux/sparc
sparc:Subject: GDB 5.0 won't build on GNU/Linux/sparc
sparc:Subject: GDB on GNU/Linux/sparc?
sparc:Subject: [PATCH] Sparc Linux stuff
sparc:Subject: [jakub@redhat.com: Re: gdb sparc/linux]
sparc:Subject: [jakub@redhat.com: gdb sparc/linux]
sparc:Subject: gdb sparc/linux
step-alarm-test:Subject: [RFA] Testsuite addition for x86 linux GDB and SIGALRM fix
step-at-end:Subject: Testsuite fix for ending-run.exp "step at end 2"
struct-thread:Subject: [PATCH RFA] process/thread/lwp identifier mega-patch
symtab:Subject: [PATCH RFA]: Fix hash table bugs in minsyms.c
symtab:Subject: [RFA] PATCH: finding a function with address
symtab:Subject: [RFA] symtab.c:  Another fix, now for gdb.c++/templates.exp regressions
symtab:Subject: [RFA] symtab.c: Fix for infinite GDB recursion in gdb.c++/classes.exp
symtab:Subject: [RFA]: search_symbols(in symtab.c) -- fix off by one error
symtab:Subject: symbol table lookup performance
symtab:Subject: unprotected references to partial symtab (core dump fix)
tags:Subject: Patch: `make tags' -vs- gdbtk, try 2
targ-solib:Subject: --target=m68k-linux VS solib-svr4
targ-solib:Subject: DT_NULL and solib-svr4.c again
watchpoint-stop:Subject: remote watchpoint support
xmalloc:Subject: [RFA] Change malloc to xmalloc
xmalloc:Subject: [RFA] Change malloc to xmalloc - resubmission
From jimb@zwingli.cygnus.com Thu Feb 15 16:04:00 2001
From: Jim Blandy <jimb@zwingli.cygnus.com>
To: Michael Elizabeth Chastain <chastain@cygnus.com>
Cc: ac131313@cygnus.com, fnasser@redhat.com, gdb-patches@sources.redhat.com, keiths@cygnus.com
Subject: Re: [RFA] Assuming malloc exists in callfwmall.exp
Date: Thu, 15 Feb 2001 16:04:00 -0000
Message-id: <np8zn7ebli.fsf@zwingli.cygnus.com>
References: <200102152015.MAA27042@bosch.cygnus.com>
X-SW-Source: 2001-02/msg00274.html
Content-length: 2138

Michael Elizabeth Chastain <chastain@cygnus.com> writes:
> > I think it's simply a property of HP's system --- perhaps a
> > characteristic of the dynamic linker, perhaps something else --- that
> > malloc is always available to the debugger, whether the program uses
> > it or not.
> 
> As Kevin Buettner pointed out, it's the normal behavior on Red Hat Linux
> natives.
> 
> It's also the normal behavior on Solaris native.  (Tested on Solaris 2.6
> native with 2.9-gnupro-99r1 and with Sun's cc 4.2).

Not if you link statically.

zwingli:play$ cat bar.c
main ()
{
  write (1, "Howdy.\n", 7);
}
zwingli:play$ gcc bar.c -o bar -g -static
zwingli:play$ gdb bar
GNU gdb 5.0-nortelpch-001112
Copyright 2000 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.  This version of GDB is supported
for customers of Red Hat, Inc..  Type "show warranty" for details.
This GDB was configured as "sparc-sun-solaris2.5.1"...
(gdb) break main
Breakpoint 1 at 0x1022c: file bar.c, line 3.
(gdb) run
Starting program: /mill/home/jimb/play/bar 
 
Breakpoint 1, main () at bar.c:3
3         write (1, "Howdy.\n", 7);
(gdb) print write (1, "bye", 3)
evaluation of this expression requires the program to have a function "malloc".
(gdb) 

And the fact that it usually works elsewhere is beside the point.  In
the case of Red Hat 7.0, it's just because there's so much garbage
linked into the most trivial executable that malloc gets pulled in.
My little test program above has 190k of code.

Unless the system is going to make documented promises to you about
what gets pulled into your executable, I don't think the GDB test
suite should require it.  The issue is irrelevant to GDB's quality.

In the case of HP, it's my impression that they went to some effort to
make this work, and the system guarantees it will work, so it's fine
to test it.  But unless there's some promise --- in the ABI, say ---
that malloc will be present in every process, the test should not be
run.

Re: Where did my patch go?

[Andrew Cagney]

A PS.

Many of these ``patches'' are not really patches. Rather they are issues
that may or may not have been followed through.  If various maintainers
don't recognize random subject lines then don't worry.

	Andrew