Can I completely remove xdc config file

Mark,
there are already some threads about the same topic. The short answer is that there is no well defined process of manually generating a C source file and a linker command file, which is in essence what XDCtools do. Please read my answers in the following threads for more details:
http://e2e.ti.com/support/embedded/bios/f/355/t/193559.aspx?pi68665=1
http://e2e.ti.com/support/embedded/bios/f/355/t/189232.aspx

Somewhere in the first thread I explained how you can use XDCtools once and then use them as your own source files. I think it's closest you can get to the full control of your source files without reinventing XDCtools. Consider that approach and let me know if you have any further questions.

I need

1) link to how to reduce the size of the generated .c file pie_p28FP.c it way to huge and scaring the V&V team

2) an easy way besides scouring the map file as to whatever .c files are being used(example task.c semaphore.c) as these have to be tested this is a life critical system

3) looking at my below .cfg file what is causing this file to be so huge

var Defaults = xdc.useModule('xdc.runtime.Defaults');
var Diags = xdc.useModule('xdc.runtime.Diags');
//var Log = xdc.useModule('xdc.runtime.Log');
//var LoggerBuf = xdc.useModule('xdc.runtime.LoggerBuf');
var Main = xdc.useModule('xdc.runtime.Main')




var BIOS = xdc.useModule('ti.sysbios.BIOS');
var Hwi = xdc.useModule('ti.sysbios.family.c28.Hwi');
var Task = xdc.useModule("ti.sysbios.knl.Task");
var Sem = xdc.useModule('ti.sysbios.knl.Semaphore');
//var Idle = xdc.useModule('ti.sysbios.knl.Idle');
//Idle.addFunc('&Cl3_Task');  


/* Create a task with priority 2 */
var taskParams = new Task.Params();
taskParams.priority = 2;
var myTask = Task.create('&Cl3_Task', taskParams);

/*
 * Create a LoggerBuf and make it the default logger for all modules.

var LoggerBufParams = new LoggerBuf.Params();
LoggerBufParams.numEntries = 16;
var logger0 = LoggerBuf.create(LoggerBufParams);
Defaults.common$.logger = logger0;

Main.common$.diags_INFO = Diags.ALWAYS_ON;
 */
Program.stack = 0x100;


/*
 * Build a custom BIOS library.  The custom library will be smaller than the
 * pre-built "instrumented" (default) and "non-instrumented" libraries.
 *
 * The BIOS.logsEnabled parameter specifies whether the Logging is enabled
 * within BIOS for this custom build.  These logs are used by the RTA and
 * UIA analysis tools.
 *
 * The BIOS.assertsEnabled parameter specifies whether BIOS code will
 * include Assert() checks.  Setting this parameter to 'false' will generate
 * smaller and faster code, but having asserts enabled is recommended for
 * early development as the Assert() checks will catch lots of programming
 * errors (invalid parameters, etc.)
 */
BIOS.libType = BIOS.LibType_Custom;
BIOS.logsEnabled = false;
BIOS.assertsEnabled = true;

Mark,
there is an appendix in SYS/BIOS User's Guide that describes how to minimize the application footprint in terms of data size and code size, under the title "Minimizing the Application Footprint". Most of these techniques will also reduce the size of the generated C file. Any further reductions I could think of are not simple, and would require additional development in the XDCtools code.
That would a whole new project, and it's not something that can be done through the message board. Also, you would have to accept a larger application size in exchange for reducing the size of the generated C file. For example, many of the macros and defines are added to that file in order to make applications smaller and more efficient. The .clink directives at the bottom of that file ensure that various constants that are not referenced from the app are removed at the link time. You could change some code in XDCtools, and remove these directives, end then end up with an app larger than necessary.

As for figuring out the source files that contributed to an application, I would recommend asking in the compiler forum. I use utilities nm and ofd that are delivered with the compiler to get various info about executables and object files, but I'm not sure what's the best way to get a list of object files whose code contributed to the application. Once you have a list of object files, you can trace them back to the source files. Except for few files, the object file names correspond to SYS/BIOS sources with .c extension.

<<As for figuring out the source files that contributed to an application, I would recommend asking in the compiler forum. I use utilities nm and ofd that are delivered with <<the compiler to get various info about executables and object files

These utilities sound like GCC and my command line does not know what they are. What I reallyneed to know is what is  sysbios.lib.

while debugging I have seen the Hwi.c function Hwi_dispatchC(register Int intNum) being executed yet its not in the map. looking below

sysbios.lib was created using BIOS.obj I NEED TO KNOW why the map only contains a _ti_sysbios_family_c28_Hwi_dispatchC__I is this code lifted from Hwi.c and placed in thebrary sysbios.lib? I have to know how these libraries are created and what EXACTLY is in them. I can also try the compiler forum but this seems to be sysbios related

                  00301de2    000000e2     sysbios.lib : BIOS.obj (.text:_ti_sysbios_knl_Semaphore_pend__E)
                  00301ec4    000000d9                 : BIOS.obj (.text:_ti_sysbios_family_c28_Hwi_clearInterrupt__E)
                  00301f9d    000000d7                 : BIOS.obj (.text:_ti_sysbios_family_c28_Hwi_disablePIEIER__E)
                  00302074    000000d3                 : BIOS.obj (.text:_ti_sysbios_family_c28_Hwi_enablePIEIER__E)
                  00302147    000000c8                 : c28_Hwi_disp.obj (.text:_ti_sysbios_family_c28_Hwi_dispatch)
                  0030220f    000000c2                 : BIOS.obj (.text:_ti_sysbios_family_c28_Hwi_Instance_init__F)