Fw: [Dpcl-user] DPCL problem with line numbers for large programs
Brought to you by:
dpcl-admin,
dwootton
From: Dave W. <dwo...@us...> - 2002-12-19 18:09:08
|
John As Albert points out, we know where the problem is with regard to the symbol tables in FORTRAN applications. Unfortunately, this is not a simple fix, and will require some significant work in the BPatch code to fix. To help us prioritize this work with other work we have, we you like your assesment of how serious the impact is to you. Is an immediate fix required, or a deadline when you require a fix? There is no question that this needs to be fixed, we are just asking to help us properly prioritize the work. Thanks Dave ----- Forwarded by Dave Wootton/Poughkeepsie/IBM on 12/19/2002 10:06 AM ----- Albert Feng/Poughkeepsie/IBM@IBMUS Sent by: dpc...@ww... 12/18/2002 10:14 AM To: John May <jo...@ll...>, dpc...@ww... cc: Subject: Re: [Dpcl-user] DPCL problem with line numbers for large programs John, It seems dpcl confused about the new symbol table generated by xlf 8.1. The old compiler (xlf 7 ) generates the 'type' information (which are the stab string look like ':t1=-29') on the per-function basis. The new compiler generated the type string in both file and function level. There is a special tag in the BPatch_function::createVariable() to check if this is a fortran program and set the typesScope accordingly. In xlf 8.1, some variables failed to find the variable type, and an error is flaged. I can recreate the problem using the MB3D.f in umt98 and a set of dummy routines such as initialize, readsmesh5,... The fix requires some structure change. Need to think through it. Albert Feng John May <jo...@ll...>@www-124.southbury.usf.ibm.com on 12/16/2002 08:31:48 PM Sent by: dpc...@ww... To: Dave Wootton/Poughkeepsie/IBM@IBMUS cc: dpc...@ww..., gy...@ll..., pa...@ll... Subject: Re: [Dpcl-user] DPCL problem with line numbers for large programs Here's an update on the DPCL line number problem I've been investigating. I've found the cause of the problem for the large C programs generated with bigprog. When a program has more than 64K line number entries in the symbol table, the XCOFF file uses an overflow header, and XCOFF_reader::readRawData isn't handling this correctly. Specifically, when handling an overflow header, this function sets the variable refS to the index of the text section that had the overflow. This index value is 1-based, so the first section is number 1. However, XCOFF_reader uses 0-based indexing for its array of sections, so there is an off-by-one error. refS should be decremented after it is set. Furthermore, in fix_lineNum, the number of line number entries to process is read from the text section header, even when it contains the overflow value of 64K. This value should probably be read from section[i].lineNumSz, which is set to the correct number even when there is an overflow. When I implement these changes by hand during a debugger run, all is well with my C test program. HOWEVER, the Fortran/C test program where I first observed this problem does not contain an overflow section, so there appears to be a second bug. I am still trying to track this down, but making the fixes I describe above doesn't solve the problem. John On Mon, Dec 09, 2002 at 02:26:46PM -0800, John May wrote: > Dave -- > > Thanks for looking into this. We've done some more experiments > with a program (below) that generates dummy C programs with > lots of functions. This lets us produce programs of arbitrary > size to investigate how that affects this bug. The program > takes as parameters a base name for a target program, the number > of functions, and the number of files into which the program > should be split. For my most recent tests, the more files > there are, the faster listmod produces output. With only > one file at large sizes, I ran out of patience waiting for > listmod after about 10 minutes. Different compilers don't > seem to have an effect, in my limited tests. Here's a chart > of the tests I've done: > > Functions files compiler works? Executable size > 8192 16 ? yes 2274883 > 16384 4 cc yes 4603723 > 16384 1 ? yes > 16384 16 ? yes 4563718 > 20480 4 cc yes 5760883 > 20480 8 cc yes 5726047 > 20480 4 newxlc_r yes 5760817 > 20480 1 cc gave up 5985634 > 21504 4 cc yes 6050163 > 21504 64 cc yes 5994856 > 22528 4 cc no 6339483 > 24576 4 cc no 6918043 > 32768 2 ? no 9378659 > 32768 1 ? gave up 9532794 > > newxlc_r is VAC 6.0.0.0. cc is, I think, 5.0.2.3. > ? under compiler means I forget to keep track for that test. > As you can see, there's a boundary between 21K and 22K functions > where listmod stops getting correct line number information. > > To generate the 21K (i.e., 21504 function) example, I did: > > bigprog prog21kx4 21504 4 > > This generated 4 .c files, which I compiled as follows: > > cc -g bigprog prog21kx4_*.c -o prog21kx4 > > Then I ran it with listmod as: > > listmod localhost prog21kx4 > > It takes a few minutes before output appears, though it's > somewhat faster for, say, a 64-way split instead of a 4-way. > > I will continue to look into this, but I thought this info > might help you too. > > John > > > /* bigprog.c */ > #include <stdio.h> > > int main( int argc, char ** argv ) > { > FILE * outfile; > int funccount, i; > int splitcount = 1; > int newfilecount; > int fileindex = 1; > char filename[1000]; > > if( argc < 3 ) { > printf( "Usage: <outfile> <function-count> " > "[<split count>]\n", argv[0] ); > return -1; > } > > funccount = atoi( argv[2] ); > if( funccount <= 1 ) { > printf( "Invalid function count: 0\n", funccount ); > return -1; > } > > if( argc > 3 ) { > splitcount = atoi( argv[3] ); > if( splitcount < 1 || splitcount > funccount ) { > printf( "Invalid split count: 0\n", splitcount ); > return -1; > } > } > > if( splitcount == 1 ) { > sprintf( filename, ".c", argv[1] ); > } else { > sprintf( filename, "_0.c", argv[1], fileindex++ ); > } > > newfilecount = funccount / splitcount; > > outfile = fopen( filename, "w" ); > if( !outfile ) { > printf( "Failed to open for writing\n", filename ); > return -1; > } > > > fprintf( outfile, "#include <stdio.h>\n" ); > fprintf( outfile, "/* File with 0 functions (including main) */\n", > funccount ); > > /* Last function (written first) just returns a value */ > fprintf( outfile, "int func0() {\n", funccount ); > fprintf( outfile, "\treturn 1;\n" ); > fprintf( outfile, "}\n"); > > /* Now write the intermediate functions */ > for( i = funccount - 1; i > 1; i-- ) { > if( i ewfilecount == 0 ) { > fclose( outfile ); > sprintf( filename, "_0.c", argv[1], fileindex++ ); > outfile = fopen( filename, "w" ); > if( !outfile ) { > printf( "Failed to open for writing\n", > filename ); > return -1; > } > } > > fprintf( outfile, "int func0() {\n", i ); > fprintf( outfile, "\treturn func0() + 1;\n", i + 1 ); > fprintf( outfile, "}\n" ); > } > > /* Finally, write main. */ > fprintf( outfile, "int main() {\n" ); > fprintf( outfile, > "\tprintf(\"Called %d functions\\n\", func2() );\n" ); > fprintf( outfile, "\treturn 0;\n" ); > fprintf( outfile, "}\n" ); > > fclose( outfile ); > > return 0; > } > _______________________________________________ > Dpcl-user mailing list > Dpc...@ww... > http://www-124.ibm.com/developerworks/oss/mailman/listinfo/dpcl-user _______________________________________________ Dpcl-user mailing list Dpc...@ww... http://www-124.ibm.com/developerworks/oss/mailman/listinfo/dpcl-user _______________________________________________ Dpcl-user mailing list Dpc...@ww... http://www-124.ibm.com/developerworks/oss/mailman/listinfo/dpcl-user |