Debugging issue wrt code compiled with gcc --function-sections flag

[Raunaq 12 <raunaq12 at in dot ibm dot com>]

Hi,

I have been looking into the issues GDB faces while debugging a binary
which has been compiled with GCC --ffunction-section option on ppc-aix
(xcoff format)

GCC does display a warning that  -
"-ffunction-sections may affect debugging on some targets"

The main problem that GDB faces while debugging such a binary is that
because each function is linked to a separate csect, scan_xcoff_symtab()
creates different 'partial symbol tables' for each csect it encounters.

And, read_xcoff_symtab() will read data present only in the specified pst.

A small example to illustrate this :-

consider a file foobar.c -
--
int main(int argc, char *argv[])
{
        int a = 5;
        return (foobar (a, *argv));
}

int foobar (int a, char* name)
        {return a++;}
---
Part of the XCOFF symbol table is shown below -

[175]   m   0x000000c9     debug     0    FILE          C:COM     foobar.c
[176]   m   0x10000360     .text     1  unamex                    .main
.....
[185]   m   0x0000007c     debug     0    psym
argv:p4=*5=*-2
.....
[189]   m   0x100003d4     .text     1  unamex                    .foobar
;;;;
[198]   m   0x0000004c     debug     0    psym                    name:p5

Because of --function-sections, main () and foobar () are assigned to
separate partial symbol tables.

If you observe [185], argv is assigned to an internal pointer type -2 which
is char*.

And, in [198] under the foobar csect, the char pointer 'name' is directly
assigned
to 'p5', which means pointer to type 5,

Now, read_xcoff_symtab() in GDB while processing pst containing foobar,
will
realise that  'name' should point to type 5, Under normal circumstances,
type_vector will contain the info that type 5 actually means char *.

But, since this is another pst, it will just assign '<incomplete type>'  to
'name'
as it does not recognize the type as it was declared in some other pst.

Something like -
(gdb)
foobar (a=5, name=<incomplete type>) at foobar.c:8
---
So, my question is that is there a specific way to deal with this issue?

I have worked on a fix which basically marks all PSTs under the same
filename as dependent to
each other and another 'type array'  to store all types that get defined in
these PSTs to
help resolve the incomplete types. But I feel that this is just addressing
part of the problem.

Any thoughts/comments would be appreciated.

Thanks & Regards,
Raunaq M Bathija