diff --git a/projects/clr/hipamd/docs/markdown/hip_profiling.md b/projects/clr/hipamd/docs/markdown/hip_profiling.md
index 4119ef47e9..772f762912 100644
--- a/projects/clr/hipamd/docs/markdown/hip_profiling.md
+++ b/projects/clr/hipamd/docs/markdown/hip_profiling.md
@@ -349,7 +349,8 @@ These options cause HCC to serialize.  Useful if you have libraries or code whic
 $32 = {_shortTid = 1, _apiSeqNum = 803}
 ```
 
-- HCC tracks all of the application memory allocations, including those from HIP and HC's "am_alloc".  These can be printed by calling the function 'hc::am_memtracker_print()'.
+- HCC tracks all of the application memory allocations, including those from HIP and HC's "am_alloc".
+If the HCC runtime is built with debug information (HCC_RUNTIME_DEBUG=ON when building HCC), then calling the function 'hc::am_memtracker_print()' will show all memory allocations. 
 An optional argument specifies a void * targetPointer - the print routine will mark the allocation which contains the specified pointer with "-->" in the printed output.
 This example shows a sample GDB session where we print the memory allocated by this process and mark a specified address by using the gdb "call" function..
 The gdb syntax also supports using the variable name (in this case 'dst'):
@@ -399,7 +400,7 @@ Program received signal SIGABRT, Aborted.
 ...
 ```
 
-Some general tips:
+### General Debugging Tips
 - The fault will be caught by the runtime but was actually generated by an asynchronous command running on the GPU.    So, the GDB backtrace will show a path in the runtime, ie inside "GI_Raise" as shown in the example above.
 - To determine the true location of the fault, force the kernels to execute synchronously by seeing the environment variables HCC_SERIALIZE_KERNEL=3 HCC_SERIALIZE_COPY=3.  This will force HCC to wait for the kernel to finish executing before retuning.  If the fault occurs during the execution of a kernel, you can see the code which launched the kernel inside the backtrace.  A bit of guesswork is required to determine which thread is actually causing the issue - typically it will the thread which is waiting inside the libhsa-runtime64.so.
 - VM faults inside kernels can be caused byi:
@@ -408,3 +409,15 @@ Some general tips:
    - synchronization issues
    - compiler issues (incorrect code generation from the compiler)
    - runtime issues 
+
+-- General debug tips:
+- 'gdb --args' can be used to conviently pass the executable and arguments to gdb.
+- From inside GDB, you can set environment variables "set env".  Note the command does not use an '=' sign:
+```
+(gdb) set env HIP_DB 1
+```
+Setting HIP_PRINT_ENV=1 and then running a HIP application will print the HIP environment variables, their current values, and usage info.
+Setting HCC_PRINT_ENV=1 and then running a HCC application will print the HCC environment variables, their current values, and usage info.
+
+
+