Re: [RFA] Fix gdb/277 by separating types

[Daniel Jacobowitz <drow@mvista.com>]

On Sun, May 12, 2002 at 10:10:04PM -0500, Michael Elizabeth Chastain wrote:
> I do build an object directory from scratch (just to avoid these
> kinds of problems).
> 
> BTW I am using gcc 2.95.3, I don't know where you got 2.95.2 from.
> 
> I bet the difference in our machines is somewhere in libc.
> I am using stock red hat linux 7.2 glibc, glibc 2.2.4-13.

Are you really?  That's interesting.  Debian does not include debug
information in the system glibc, I'm quite surprised that Red Hat does.

> It's reproducing on my machine.  Here's a shorter recipe:
> 
>   ./gdb gdb.base/break
>   (gdb) break main
>   (gdb) run
>   (gdb) maint print symbols symbols_output
> 
> Have a look at the end of symbols_output in the tarball.
> Mine is reproducibly crapping out in file 'init.c' here:
> 
>    typedef void (*__gconv_end_fct)();
>    typedef int (*__gconv_fct)();
>    struct __gconv_info {
>        size_t __nsteps;
>        struct __gconv_step *__steps;
>        struct __gconv_step_data __data[0];
>    };
> 
>    typedef int (*__gconv_init_fct)();
>    struct __gconv_step {
> 
> When I do maint-print-symbols with gdb 5.2, it runs fine,
> and gives me this output for __gconv_step:
> 
>    typedef int (*__gconv_init_fct)(struct __gconv_step *);
>    struct __gconv_step {
>        struct __gconv_loaded_object *__shlib_handle;
>        const char *__modname;
>        int __counter;
>        char *__from_name;
>        char *__to_name;
>        int (*__fct)(struct __gconv_step *, struct __gconv_step_data *, const unsigned char **, const unsigned char *, unsigned char **, size_t *, int, int);
>        int (*__init_fct)(struct __gconv_step *);
>        void (*__end_fct)(struct __gconv_step *);
>        int __min_needed_from;
>        int __max_needed_from;
>        int __min_needed_to;
>        int __max_needed_to;
>        int __stateful;
>        void *__data;
>    };

The const in __fct is probably what's killing it...

> In the stack trace, I'm seeing it crap out on c_print_type of
> __shlib_handle.  __gconv_loaded_object is a forward reference,
> but it is not defined in this symtab: it is defined in a different
> symtab.

Sure enough, I can reproduce the failures if I use a libc with debug
symbols.  I'll investigate; patch tabled for the moment.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer