Thanks for those of you who have replied to my problem. 
Andre de Leiradella wrote in
news:000501c3829d$cbcea620$dd70e40d at bra.xerox.com:
Does TD32 show the message "Not enough memory to load symbol table"
when you load your executable? If so, you are failing to enable debug
info on either the compiler or linker or both. You said that you had
debug info enabled with “-v”, but if you see this message you should
check your makefiles again.
no I don’t get that error though on occasion I do get the “debug info is
old, do I wish to use it” msg but that’s understandable when I recompile a
project.
If you don’t get any error message inside TD32 then what’s probably
hapenning is that TD32 can’t find your source code files, so it shows
only what it can: the assembly window. Is this case you’d be able to
watch variables and see symbols in the assembly window though. To make
TD32 find your source code files, go to “Options” and “Path for
source…”. Enter the directories where your source code files are
located separeted by a semicolon. Don’t use Windows’ long file names,
TD32 uses spaces to separate different paths, just like the semicolon.
hmm, setting the path source explicitly still doesn’t help 
I tried it
using both the traditional 8.3 naming format and the normal windows naming
format. I don’t think not being able to find source directory is the
problem.
Like I also mentioned before though, debugging projects that don’t use sdl
I’m able to do source debugging on them fine.
Well, here’s how my makefile for the project looks like:
Borland C++ tools
IMPLIB= Implib
ILINK32= ILink32
BRC32= Brc32
TLIB= TLib
TASM32= Tasm32
CC= BCC32
Compiler and Linker flags
LD_FLAGS=-v
C_FLAGS=-y -v
BCC32 RT lib: cw32.lib static
BCC32RTLIB=cw32.lib SDL.lib SDLmain.lib SDL_image.lib
BCC32 Startup: c0x32.obj-console, c0w32.obj-winapi
BCC32STARTUP=c0w32.obj
SRCS=
E:\Borland\myworkspace\Test.cpp
OBJS=
Test.obj
oDir=E:\Borland\myworkspace\
Dependency Rules
ProjectExecutable :$(OBJS)
cd $(oDir)
$(ILINK32) @&&|-c +
$(LD_FLAGS) +
$(BCC32STARTUP) +
$(OBJS), +
“E:\Borland\myworkspace\test.exe”, , +
import32.lib $(BCC32RTLIB)
|
Test.obj :"E:\Borland\myworkspace\Test.cpp"
cd $(oDir)
$(CC) -c $(C_FLAGS) -o$@ “E:\Borland\myworkspace\Test.cpp”
If what you want is to debug into SDL calls, then it’s a whole
different problem. I can’t help you with this, I just debug my code
and hope that SDL works as documented (and it does!). But here’s a
hint: compile SDL from the source code with debug info enabled and
make the path for source files in TD32 to point to SDL source code
files besides your own files.
yes yes, you just hit the nail on the head. that’s all I really wanna
do. I just want to do debugging on my code only and have no intention of
tracing into SDL calls. I’m just going to assume that SDL itself is bugfree
and the calls to it does what it’s suppose to. Afterall, it’s my code that
needs debugging. 
Like the poster before you suggested, I might need to compile the SDL
source with debuggy info on. I’ll do that if that’s what it’ll take to
allow me to do debugging on my projects but would like to know first if
that’s really the problem; there’s no guarantee that even this will allow
me to do what I want. If there’s a way to get this to work without having
to do SDL source recompiling w/ debugging on then that’s all the better.
Thanks again guys