This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: [RFA] Assuming malloc exists in callfwmall.exp



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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]