* "Cannot access memory at address 0x175f80"
@ 2003-09-26 17:46 Andrew Greenlaw
2003-09-26 17:50 ` Daniel Jacobowitz
0 siblings, 1 reply; 4+ messages in thread
From: Andrew Greenlaw @ 2003-09-26 17:46 UTC (permalink / raw)
To: gdb
Hi. I'm debugging a C++ tool (called apple) that's loaded as a
dynamic library into a C - or C++ program (called orange) . Apple is
compiled with g++ 3.3.1, binutils 2.14, and debugging symbols are
enabled. Orange is a big unknown (meaning: I don't know how it was
compiled) and it has no debugging symbols. The gdb version is 5.3
Here are the flags used to compile Apple:
# -gdwarf-2 -g3 used to enable stepping through macro execution under
gdb 5.3 The explanation's under gdb 5.3 release notes.
Compile:g++ -std=c++98 -Wall -DLINUX -gdwarf-2 -g3 -D__USE_GNU
-D_GNU_SOURCE -fPIC file_name.cpp
Link:
g++ -shared $(LIBS) $(OBJSCHEF) $(PLIOBJSVCS_PLI)
InterfaceObjectVCS_PLI.o -o $@ -lc gdwarf-2 -g3 -fPIC
g++ -MD -std=c++98 -shared -lc -gdwarf-2 -g3 -fPIC <object files> -o
libapple.so
When I go to debug apple, I run "gdb <program name>", then use the
"add-symbol-file <apple's path & filename> -readnow" gdb comman to load
the symbols from apple. From there, I can set breakpoints in C++ class
methods, no problem. But, there is 1 function (so, non-OO code), where
if I try to set a breakpoint, I get the following:
(gdb) break nc_signal_raised
Cannot access memory at address 0x175f80
If I do an "nm" on the library, I get:
00175f80 T nc_signal_raised
Indicating that the address read by gdb is correct.
On a related, but less important note, when use ddd to debug & go to
a source file, I always get: "<src_file_name>" is at address 0x10f5f0
<part_of_src_file_name> but contains no code.
And yet I can set breakpoints or step through the code. What's
going on?
Any help you can offer will be appreciated. I've been working on
this for 2 weeks, read every posting or piece of documentation I can
find. I'm at my wits' end!
--
Andrew Greenlaw
****
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: "Cannot access memory at address 0x175f80" 2003-09-26 17:46 "Cannot access memory at address 0x175f80" Andrew Greenlaw @ 2003-09-26 17:50 ` Daniel Jacobowitz 2003-09-26 18:39 ` Andrew Greenlaw 0 siblings, 1 reply; 4+ messages in thread From: Daniel Jacobowitz @ 2003-09-26 17:50 UTC (permalink / raw) To: Andrew Greenlaw; +Cc: gdb On Fri, Sep 26, 2003 at 01:40:16PM -0400, Andrew Greenlaw wrote: > Hi. I'm debugging a C++ tool (called apple) that's loaded as a > dynamic library into a C - or C++ program (called orange) . Apple is > compiled with g++ 3.3.1, binutils 2.14, and debugging symbols are > enabled. Orange is a big unknown (meaning: I don't know how it was > compiled) and it has no debugging symbols. The gdb version is 5.3 > > Here are the flags used to compile Apple: > # -gdwarf-2 -g3 used to enable stepping through macro execution under > gdb 5.3 The explanation's under gdb 5.3 release notes. > Compile:g++ -std=c++98 -Wall -DLINUX -gdwarf-2 -g3 -D__USE_GNU > -D_GNU_SOURCE -fPIC file_name.cpp > > > Link: > g++ -shared $(LIBS) $(OBJSCHEF) $(PLIOBJSVCS_PLI) > InterfaceObjectVCS_PLI.o -o $@ -lc gdwarf-2 -g3 -fPIC > g++ -MD -std=c++98 -shared -lc -gdwarf-2 -g3 -fPIC <object files> -o > libapple.so > > When I go to debug apple, I run "gdb <program name>", then use the > "add-symbol-file <apple's path & filename> -readnow" gdb comman to load > the symbols from apple. From there, I can set breakpoints in C++ class > methods, no problem. But, there is 1 function (so, non-OO code), where > if I try to set a breakpoint, I get the following: > > (gdb) break nc_signal_raised > Cannot access memory at address 0x175f80 > > If I do an "nm" on the library, I get: > 00175f80 T nc_signal_raised > > Indicating that the address read by gdb is correct. Unlikely, since the library is not loaded at a base address of 0. > On a related, but less important note, when use ddd to debug & go to > a source file, I always get: "<src_file_name>" is at address 0x10f5f0 > <part_of_src_file_name> but contains no code. > > And yet I can set breakpoints or step through the code. What's > going on? > > Any help you can offer will be appreciated. I've been working on > this for 2 weeks, read every posting or piece of documentation I can > find. I'm at my wits' end! Why are you using add-symbol-file? Is the loader not done as a dlopen, i.e. are you dealing with something that has its own dynamic loader? If it's dlopen'd, gdb should automatically handle it. It seems unlikely that add-symbol-file without specifying a text offset is right, too. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: "Cannot access memory at address 0x175f80" 2003-09-26 17:50 ` Daniel Jacobowitz @ 2003-09-26 18:39 ` Andrew Greenlaw 2003-09-26 18:39 ` Daniel Jacobowitz 0 siblings, 1 reply; 4+ messages in thread From: Andrew Greenlaw @ 2003-09-26 18:39 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: gdb I was specifying add-symbol-file, because when I start "orange", none of the symbols from "apple" are accessible. In DDD, the source code for Apple's files don't even appear in the "open source" menu. The only 2 ways to make those files appear are 1) to run the program once, then set breakpoints, then re-run, or 2) use the add-symbol-file command. I admit I wasn't using it in an informed manner, but it worked for the other symbols. I tried a little experiment: I started gdb, used the add-symbol-file command, then entered "break nc_signal_raised". It said "Cannot access memory at address 0x175f9c". I then exited gdb, started over, and this time, instead of add-symbol-file, ran the program. when the program exitted, I typed "break nc_signal_raised", It said "Breakpoint 1 at 0x40fb2f9f: file /sopt/ldv-dev/tools/src/main.cc, line 8.". So that was part of the problem. Now the bad news. If I try to re-run, this particular breakpoint can't be inserted. After that encouraging message above, I hit the "run" button in ddd, and got: (gdb) run snap1 (no debugging symbols found)...Error in re-setting breakpoint 1: Function "nc_signal_raised" not defined. Error in re-setting breakpoint 1: Function "nc_signal_raised" not defined. Error in re-setting breakpoint 1: Function "nc_signal_raised" not defined. Error in re-setting breakpoint 1: Function "nc_signal_raised" not defined. Error in re-setting breakpoint 1: Function "nc_signal_raised" not defined. Error in re-setting breakpoint 1: Function "nc_signal_raised" not defined. Error in re-setting breakpoint 1: Function "nc_signal_raised" not defined. Error in re-setting breakpoint 1: Function "nc_signal_raised" not defined. Error in re-setting breakpoint 1: Function "nc_signal_raised" not defined. ncsim: 05.00-s005: (c) Copyright 1995-2003 Cadence Design Systems, Inc. ncsim: *W,DLNOHV: Unable to find an 'hdl.var' file to load in. Error in re-setting breakpoint 1: Function "nc_signal_raised" not defined. Error in re-setting breakpoint 1: Function "nc_signal_raised" not defined. Error in re-setting breakpoint 1: Function "nc_signal_raised" not defined. Error in re-setting breakpoint 1: Function "nc_signal_raised" not defined. Error in re-setting breakpoint 1: Function "nc_signal_raised" not defined. Error in re-setting breakpoint 1: Function "nc_signal_raised" not defined. Any Ideas? Daniel Jacobowitz wrote: >On Fri, Sep 26, 2003 at 01:40:16PM -0400, Andrew Greenlaw wrote: > > >> Hi. I'm debugging a C++ tool (called apple) that's loaded as a >>dynamic library into a C - or C++ program (called orange) . Apple is >>compiled with g++ 3.3.1, binutils 2.14, and debugging symbols are >>enabled. Orange is a big unknown (meaning: I don't know how it was >>compiled) and it has no debugging symbols. The gdb version is 5.3 >> >> Here are the flags used to compile Apple: >># -gdwarf-2 -g3 used to enable stepping through macro execution under >>gdb 5.3 The explanation's under gdb 5.3 release notes. >> Compile:g++ -std=c++98 -Wall -DLINUX -gdwarf-2 -g3 -D__USE_GNU >>-D_GNU_SOURCE -fPIC file_name.cpp >> >> >> Link: >> g++ -shared $(LIBS) $(OBJSCHEF) $(PLIOBJSVCS_PLI) >>InterfaceObjectVCS_PLI.o -o $@ -lc gdwarf-2 -g3 -fPIC >>g++ -MD -std=c++98 -shared -lc -gdwarf-2 -g3 -fPIC <object files> -o >>libapple.so >> >> When I go to debug apple, I run "gdb <program name>", then use the >>"add-symbol-file <apple's path & filename> -readnow" gdb comman to load >>the symbols from apple. From there, I can set breakpoints in C++ class >>methods, no problem. But, there is 1 function (so, non-OO code), where >>if I try to set a breakpoint, I get the following: >> >> (gdb) break nc_signal_raised >>Cannot access memory at address 0x175f80 >> >> If I do an "nm" on the library, I get: >> 00175f80 T nc_signal_raised >> >> Indicating that the address read by gdb is correct. >> >> > >Unlikely, since the library is not loaded at a base address of 0. > > > >> On a related, but less important note, when use ddd to debug & go to >>a source file, I always get: "<src_file_name>" is at address 0x10f5f0 >><part_of_src_file_name> but contains no code. >> >> And yet I can set breakpoints or step through the code. What's >>going on? >> >> Any help you can offer will be appreciated. I've been working on >>this for 2 weeks, read every posting or piece of documentation I can >>find. I'm at my wits' end! >> >> > >Why are you using add-symbol-file? Is the loader not done as a dlopen, >i.e. are you dealing with something that has its own dynamic loader? >If it's dlopen'd, gdb should automatically handle it. > >It seems unlikely that add-symbol-file without specifying a text offset >is right, too. > > > -- Andrew Greenlaw, Advanced Verification Group Agere Systems of Ottawa, ON. Intranet page: http://ottawa/~andrewg/ E-mail: andrewg@agere.com, Phone: (613)768-8738, Fax: (768)768-8710 **** "A mathematician is a device for turning coffee into theorems." - Paul Erdos **** ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: "Cannot access memory at address 0x175f80" 2003-09-26 18:39 ` Andrew Greenlaw @ 2003-09-26 18:39 ` Daniel Jacobowitz 0 siblings, 0 replies; 4+ messages in thread From: Daniel Jacobowitz @ 2003-09-26 18:39 UTC (permalink / raw) To: Andrew Greenlaw; +Cc: gdb On Fri, Sep 26, 2003 at 02:16:53PM -0400, Andrew Greenlaw wrote: > I was specifying add-symbol-file, because when I start "orange", > none of the symbols from "apple" are accessible. In DDD, the source > code for Apple's files don't even appear in the "open source" menu. The > only 2 ways to make those files appear are 1) to run the program once, > then set breakpoints, then re-run, or 2) use the add-symbol-file > command. I admit I wasn't using it in an informed manner, but it worked > for the other symbols. > > I tried a little experiment: I started gdb, used the > add-symbol-file command, then entered "break nc_signal_raised". It said > "Cannot access memory at address 0x175f9c". I then exited gdb, started > over, and this time, instead of add-symbol-file, ran the program. when > the program exitted, I typed "break nc_signal_raised", It said > "Breakpoint 1 at 0x40fb2f9f: file /sopt/ldv-dev/tools/src/main.cc, line > 8.". So that was part of the problem. > > Now the bad news. If I try to re-run, this particular breakpoint > can't be inserted. After that encouraging message above, I hit the > "run" button in ddd, and got: > > (gdb) run snap1 > (no debugging symbols found)...Error in re-setting breakpoint 1: > Function "nc_signal_raised" not defined. > Error in re-setting breakpoint 1: > Function "nc_signal_raised" not defined. > Error in re-setting breakpoint 1: > Function "nc_signal_raised" not defined. > Error in re-setting breakpoint 1: > Function "nc_signal_raised" not defined. > Error in re-setting breakpoint 1: > Function "nc_signal_raised" not defined. > Error in re-setting breakpoint 1: > Function "nc_signal_raised" not defined. > Error in re-setting breakpoint 1: > Function "nc_signal_raised" not defined. > Error in re-setting breakpoint 1: > Function "nc_signal_raised" not defined. > Error in re-setting breakpoint 1: > Function "nc_signal_raised" not defined. > ncsim: 05.00-s005: (c) Copyright 1995-2003 Cadence Design Systems, Inc. > ncsim: *W,DLNOHV: Unable to find an 'hdl.var' file to load in. > Error in re-setting breakpoint 1: > Function "nc_signal_raised" not defined. > Error in re-setting breakpoint 1: > Function "nc_signal_raised" not defined. > Error in re-setting breakpoint 1: > Function "nc_signal_raised" not defined. > Error in re-setting breakpoint 1: > Function "nc_signal_raised" not defined. > Error in re-setting breakpoint 1: > Function "nc_signal_raised" not defined. > Error in re-setting breakpoint 1: > Function "nc_signal_raised" not defined. > > Any Ideas? Sure, it's noisy, but does the breakpoint eventually get defined? If not, set stop-on-solib-events to 1 and then hit continue until info shared reports that module loaded. Then enable the breakpoint. > > Daniel Jacobowitz wrote: > > >On Fri, Sep 26, 2003 at 01:40:16PM -0400, Andrew Greenlaw wrote: > > > > > >>Hi. I'm debugging a C++ tool (called apple) that's loaded as a > >>dynamic library into a C - or C++ program (called orange) . Apple is > >>compiled with g++ 3.3.1, binutils 2.14, and debugging symbols are > >>enabled. Orange is a big unknown (meaning: I don't know how it was > >>compiled) and it has no debugging symbols. The gdb version is 5.3 > >> > >> Here are the flags used to compile Apple: > >># -gdwarf-2 -g3 used to enable stepping through macro execution under > >>gdb 5.3 The explanation's under gdb 5.3 release notes. > >> Compile:g++ -std=c++98 -Wall -DLINUX -gdwarf-2 -g3 -D__USE_GNU > >>-D_GNU_SOURCE -fPIC file_name.cpp > >> > >> > >> Link: > >> g++ -shared $(LIBS) $(OBJSCHEF) $(PLIOBJSVCS_PLI) > >>InterfaceObjectVCS_PLI.o -o $@ -lc gdwarf-2 -g3 -fPIC > >>g++ -MD -std=c++98 -shared -lc -gdwarf-2 -g3 -fPIC <object files> -o > >>libapple.so > >> > >> When I go to debug apple, I run "gdb <program name>", then use the > >>"add-symbol-file <apple's path & filename> -readnow" gdb comman to load > >>the symbols from apple. From there, I can set breakpoints in C++ class > >>methods, no problem. But, there is 1 function (so, non-OO code), where > >>if I try to set a breakpoint, I get the following: > >> > >> (gdb) break nc_signal_raised > >>Cannot access memory at address 0x175f80 > >> > >> If I do an "nm" on the library, I get: > >> 00175f80 T nc_signal_raised > >> > >> Indicating that the address read by gdb is correct. > >> > >> > > > >Unlikely, since the library is not loaded at a base address of 0. > > > > > > > >> On a related, but less important note, when use ddd to debug & go to > >>a source file, I always get: "<src_file_name>" is at address 0x10f5f0 > >><part_of_src_file_name> but contains no code. > >> > >> And yet I can set breakpoints or step through the code. What's > >>going on? > >> > >> Any help you can offer will be appreciated. I've been working on > >>this for 2 weeks, read every posting or piece of documentation I can > >>find. I'm at my wits' end! > >> > >> > > > >Why are you using add-symbol-file? Is the loader not done as a dlopen, > >i.e. are you dealing with something that has its own dynamic loader? > >If it's dlopen'd, gdb should automatically handle it. > > > >It seems unlikely that add-symbol-file without specifying a text offset > >is right, too. > > > > > > > > -- > Andrew Greenlaw, Advanced Verification Group > Agere Systems of Ottawa, ON. Intranet page: > http://ottawa/~andrewg/ > E-mail: andrewg@agere.com, Phone: (613)768-8738, Fax: > (768)768-8710 > **** > "A mathematician is a device for turning coffee into theorems." > - Paul Erdos > **** > > > > -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2003-09-26 18:39 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-09-26 17:46 "Cannot access memory at address 0x175f80" Andrew Greenlaw 2003-09-26 17:50 ` Daniel Jacobowitz 2003-09-26 18:39 ` Andrew Greenlaw 2003-09-26 18:39 ` Daniel Jacobowitz
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox