From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kevin Buettner To: Fernando Nasser , Michael Elizabeth Chastain , ac131313@cygnus.com, keiths@cygnus.com, gdb-patches@sources.redhat.com Subject: Re: [RFA] Assuming malloc exists in callfwmall.exp Date: Thu, 15 Feb 2001 06:54:00 -0000 Message-id: <1010215145030.ZM8431@ocotillo.lan> References: <200102150327.TAA14419@bosch.cygnus.com> <3A8B9B62.1DE46975@redhat.com> <3A8B9F36.B7A6DE25@redhat.com> X-SW-Source: 2001-02/msg00248.html 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
, 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