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

[Jim Blandy <jimb@zwingli.cygnus.com>]

Here's the whole story regarding callfwmall.{c,exp}.  Some of this is
repetition, but I want to put it all in one place:

Whenever GDB needs to construct a literal array in the target memory
(e.g., a string literal, or an array literal like {0, 1, 2}), it calls
malloc in the inferior to find space for the value, writes the
contents, and then uses the malloc'd block's address as the value of
the array literal.

Naturally, this only works if the inferior actually has a malloc
implementation linked in somewhere, and GDB has the ability to invoke
functions in the inferior for this target.

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.

The callfwmall.{c,exp} test file was introduced to test this behavior,
as part of a grand merge of HP's changes in 1998.  One of the most...
um... memorable characteristics of the changes was that, when the work
was originally being done at HP, the engineers were told not to worry
about whether their version of GDB could still work on platforms other
than HP-UX.  So the changes the Cygnus folks were trying to merge were
often completely inappropriate for other platforms; they had to do
their best to fix them up for inclusion in the main sources.

So this file tests a behavior which is not promised or expected on
systems other than HP-UX.  It would be appropriate to move it to
gdb.hp, so the file would be omitted completely on non-HP systems, or
to xfail all the tests in the file on non-HP systems.

I agree with Kevin that it's not worth making it work on systems that
don't have malloc.  There is no portable way I can see to tell what
portions of the address space might be safe for GDB to use --- you
need intimate knowledge of the target program's environment.  But the
fact that someone *could* do so argues for the "XFAIL on all but a
selected set of systems, initially only HP" approach, instead of
moving it to gdb.hp.