This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: "Cannot access memory at address 0x175f80"
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