gdb and LD_PRELOAD -- redux

["Arthur H. Gold" <agold at bga dot com>]

A couple of weeks ago I posted to this list concerning the fact that in
the presence of a preloaded library, gdb fails to respect breakpoints
(that _are_ set successfully).

Unfortunately, it seems to have passed without comment.

Here is an example:
aoxomoxoa:~/VMTRACE/BLAH$ gdb blah
GNU gdb 4.17.0.14 with Linux support
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-redhat-linux"...
(gdb) set environment LD_PRELOAD /home/agold/VMTRACE/libvmtrace.o
(gdb) break main
Breakpoint 1 at 0x8048877: file blah.c, line 54.
(gdb) run
Starting program: /home/agold/VMTRACE/BLAH/blah

/home/agold/VMTRACE/BLAH
hey
address of sigact is 80624a0
result of stat is 0
result of lstat is 0
i am the parent
i am the child (1)

handler is: 080487a0

application handler is about to , and has, run

handler is: 080487a0

application handler is about to , and has, run

Program exited normally.
You can't do that without a process to debug
(gdb) bin   cdrom  etc     home  lost+found  opt   root  tmp    var
boot  dev    floppy  lib   mnt         proc  sbin  usr

[The preloaded library provides a virtual memory tracing facility, using
memory protections and handling of the resultant SIGSEGVs. It relies
heavily on function interposition. The program "blah" is just a toy
program that sets a handler, protects some memory and ultimately
forks/execs an `ls']

gdb-4.18 has the same problem; I tried HJ Lu's 4.17.14 in the hope that,
given its reputation for better shared object support, it would work in
this case as well.

Many thanks.
--ag

-- 
Artie Gold, Austin, TX  (finger the cs.utexas.edu account for more info)
mailto:agold@bga.com or mailto:agold@cs.utexas.edu
--