Even if it's reproducible, tech support most likely doesn't want to see 6000 lines of C code with a problem buried in the middle of it.
In most cases that I've witnessed, a bug can usually be narrowed down to about 20 to 30 lines of C at the most. The only cases where a really large file is actually useful is when reporting bugs with something where you suspect it's a size problem, rather than a library or kernel problem. For example, some utilities may have a default array size that may cause trouble when it needs to resize that array for something bigger. In this case, tech support may ask you for a tar file with everything in it. Luckily, tar files are easy to create. For example, if you're developing your product in /src/projects/xyzzy and they want to see everything in that directory, you can perform the following steps:
# cd /src/projects # tar cvf xyzzy.tar xyzzy
This will “suck” everything out of the xyzzy directory (and all subdirectories too!) into the file called xyzzy.tar. If this resulting tar file is huge, you can save some download time and disk space by compressing it with gzip:
# gzip -9v xyzzy.tar xyzzy.tar: 60.2% -- replaced with xyzzy.tar.gz
You'd then send the support people the xyzzy.tar.gz file (generally by ftp rather than as an email attachment :-)).