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

[Kevin Buettner <kevinb at cygnus dot com>]

On Feb 15,  4:19am, Fernando Nasser wrote:

> I may have found a use for this test:
> 
> test the error message issued when no malloc() is available.
> 
> We can use Michaels code to test for malloc() and skip the tests if
> malloc() is present.
> 
> If malloc() is NOT present, then we leave (do not delete) one of the
> tests that has a string argument -- just one is enough -- and check for
> the error message that is issued.

I am in favor of this very much abbreviated test.

> Question: which target would not have malloc() available?  Some embedded
> target linked with newlib where neither the program nor any of the
> library functions it calls use malloc()?

That sounds right to me.

It *seemed* to me that it should be possible to construct an
executable which wouldn't have malloc for nearly any target.  But this
turns out to be very difficult.  My idea was to take a small program
which didn't call malloc(), nor any C library functions and statically
link it.

To that end, I played around with the following program on my Linux
box...

int
main (int argc, char **argv)
{
  return 0;
}

I compiled it statically, so that malloc wouldn't creep in through
the dynamic linker (ld-linux.so.2 defines a rudimentary malloc via
a weak symbol that the dynamic linker uses to load shared libraries).
But, it turns out that malloc is still linked in anyway...

(gdb) b malloc
Breakpoint 1 at 0x8048c7a: file malloc.c, line 2691.
(gdb) r
Starting program: /home/kev/ctests/empty 

Breakpoint 1, __libc_malloc (bytes=8) at malloc.c:2697
2697    malloc.c: No such file or directory.
(gdb) bt
#0  __libc_malloc (bytes=8) at malloc.c:2697
#1  0x8053824 in _dl_important_hwcaps (platform=0x0, platform_len=0, 
    sz=0x809c470, max_capstrlen=0x809c474) at dl-support.c:189
#2  0x804d856 in _dl_init_paths (llp=0x0) at dl-load.c:576
#3  0x80536d7 in non_dynamic_init () at dl-support.c:143
#4  0x8053ba0 in __libc_init (argc=1, argv=0xbffffac4, envp=0xbffffacc)
    at set-init.c:23
#5  0x8053a1b in init (argc=1, argv=0xbffffac4, envp=0xbffffacc)
    at ../sysdeps/unix/sysv/linux/init-first.c:96
#6  0x8048294 in __libc_start_main (main=0x80481dc <main>, argc=1, 
    ubp_av=0xbffffac4, init=0x80480b4 <_init>, fini=0x808c680 <_fini>, 
    rtld_fini=0, stack_end=0xbffffabc) at ../sysdeps/generic/libc-start.c:109

I suspect that most targets which use glibc will show similar results.
It would be possible to supply alternate runtime initialization code,
but I think that putting the end result in the testsuite would result
in something that is hard to maintain.

Anyway, as I mentioned earlier, I am in favor of Fernando's abbreviated
tests.

Kevin