Categories
 |
GDB Cannot access memory at address …
I always have problem with my SuSE x86-64 machine when it come to use gdb because we are using -gstabs+ option to generate debug information.
Avery time I run GDB it will tell me that it cannot access memory:
- GNU gdb 6.8
- This GDB was configured as "x86_64-suse-linux"...Using host libthread_db library "/lib64/libthread_db.so.1".
- (gdb) b main
- Breakpoint 1 at 0x4005c3: file t.cpp, line 12.
- (gdb) set args 1 2 3 4
- (gdb) run
- Starting program: /home/dmitriy/source/test/gdb/t 1 2 3 4
- Breakpoint 1, main (n=Cannot access memory at address 0x8000fb6a84fc
- ) at t.cpp:12
- 12 }
- (gdb) p n
- Cannot access memory at address 0x8000fb6a84fc
So I get tired of seeing this message and unable to use gdb and decided to debug the debugger.
It did not take much time to found why address was not accessible: the GDB incorrectly calculates the address!
It suppose to get address of the variable by (rsp+offset). Unfortunately, the offset
was incorrect. Compiler set offset for something like -4, -8, etc. But GDB will read it as 0×7FFFFFF8, which is a positive number and after rsp+offset it usually goes to something like 0×8000fb6a84fc, instead of 0×7FFFfb6a84fc.
After digging the GDB code I conclude (I could be wrong) that the settings for sind-extend option is not correct for x86-64.
I found reference that indicates: The addressing modes were not dramatically changed from 32-bit mode, except that addressing was extended to 64 bits, physical addressing is now sign extended.
In the GDB source, elfxx-target.h defines elf_backend_sign_extend_vma as 0 (not sign-extended).
In order to override this settings I added into bfd/elf64-x86-64.c line:
- + #define elf_backend_sign_extend_vma 1
- #include "elf64-target.h"
After recompiling GDB I can see all variables!!!.
- --- ../gdb-6.8.src/bfd/elf64-x86-64.c 2008-06-07 19:27:36.000000000 -0400
- +++ bfd/elf64-x86-64.c 2008-06-07 18:30:47.000000000 -0400
- @@ -3875,6 +3875,9 @@
- #define elf_backend_hash_symbol \
- elf64_x86_64_hash_symbol
- +/* DZ */
- +#define elf_backend_sign_extend_vma 1
- +
- #include "elf64-target.h"
- /* FreeBSD support. */
Why my code is running slow on MAC 10.4
I had a complaint that performance of the program was degraded after machine was upgraded to 10.4.
After investigation it is appear that system call ‘getcwd‘ become very expensive call where internally it is iterates through the each parent directory and collect information to construct the path rather then remember the program’s current folder.
Since this system call was use to save the name of a working directory to return to it later, the solution was to replace it with system calls open+fchdir that will actually do the same work. This was recommended in man pages for getcwd (MAC):
These routines have traditionally been used by programs to save the name
of a working directory for the purpose of returning to it. A much faster
and less error-prone method of accomplishing this is to open the current
directory (’.') and use the fchdir(2) function to return.
