From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jim Blandy To: Michael Elizabeth Chastain Cc: fnasser@redhat.com, ac131313@cygnus.com, gdb-patches@sources.redhat.com, keiths@cygnus.com Subject: Re: [RFA] Assuming malloc exists in callfwmall.exp Date: Thu, 15 Feb 2001 11:56:00 -0000 Message-id: References: <200102151700.JAA26371@bosch.cygnus.com> X-SW-Source: 2001-02/msg00261.html 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.