[SOLVED] gdb reports "Cannot access memory at address 0x8049088".

stf92 · 07-11-2011, 08:17 AM

Kernel 2.6.21.5, slackware 12.0
nasm 2.03.01
ld 2.17
GNU gdb 6.6
This GDB was configured as "i486-slackware-linux".

Hi:

Code:

semoi@darkstar:~/ata$ nasm -f elf -g -o t1.o t1.s -l t1.l
semoi@darkstar:~/ata$ cat t1.l
     1                                  section         .data
     2 00000000 45                      juan    db              0x45
     3                                  
     4                                  section         .text
     5                                                  global _start
     6                                  _start:
     7 00000000 8025[00000000]03                and byte[juan],03
     8 00000007 90                              nop
     9                                  
semoi@darkstar:~/ata$ ld -o t1 t1.o
semoi@darkstar:~/ata$ gdb t1
GNU gdb 6.6
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i486-slackware-linux"...
Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) break _start
Breakpoint 1 at 0x8048080: file t1.s, line 7.
(gdb) print juan
Cannot access memory at address 0x8049088
(gdb) quit
semoi@darkstar:~/ata$

What could the cause of the message output by gdb possibly be? Reading some tutorials, I've learn the flat memory model is used in linux. So, in particular, I needn't care about the DS segment register.

Also, line 7 in the listing above, suggests nasm is assuming 32-bit addressing and so, I think it is using the flat memory model.

sundialsvcs · 07-11-2011, 10:15 AM

There are various possibilities to consider:

How does the debugger resolve the name, "juan," to an address? Is this, in fact, the correct address? (Or, are the register values meaningless?
If you are setting a breakpoint at the "start" point, has the program actually initialized itself yet?

In general, first you have to assess what you actually see at the point of failure, then you need to determine if what you are seeing is "garbage." Only when you know that you can trust what you are looking at can you draw any conclusions from it.

stf92 · 07-11-2011, 11:30 AM

Hi:

Thanks for your reply. I discovered that if I substituted
juan db 0x45

for
juan db 0x44,0x33,0x22,0x11

then
(gdb) print juan

did not produce any error. I infer gdb is, by default, trying to access juan as a double word (four bytes). Then it goes out of the data section in the example in my first post. I'll see how to modify the print command to make it print only one byte.

stf92 · 07-11-2011, 06:11 PM

Hi:

x is the gdb command I needed (info gdb -> data::):

Code:

(gdb) x/xb &juan
0x8049084 <juan>:       0x45
(gdb) x/1xb &juan
0x8049084 <juan>:       0x45
(gdb)