|
Sherry Chen
07/24/2008 8:01 PM
post11040
|
I am developing qnx drivers that use .so files.
Often my debug session does not break on the breakpoints I set up after I sych my source code with perforce. If it
happens, I have to re-import my code and start from scratch. Sometime, it still does not work.
Today I ran two debug configurations, one for io-net, one for io-pkt. Both code uses the same devn-bcm5691.so on the
target system. io-net session would break as I have setup.
I kill the io-net session (debug tab display empty window) and start the io-pkt session. The io-pkt session would not
break. I have stepped through the code and am sure that devn-bcm5691.so was loaded. And yet it does not break and
console display the following messages. The program run through, because my debugging print shows on the screen.
------------------------------------------
Cannot remove breakpoints because program is no longer writable.
It might be running in another process.
Further execution is probably impossible.
Cannot remove breakpoints because program is no longer writable.
It might be running in another process.
Further execution is probably impossible.
--------------------------------------------
This scenario can be repeated after I reboot the target system.
I am not sure what the IDE system use to keep the breakpoints or other debug information from session to session. My
guess is these files are locked and not cleared from one debug session to the other.
Please help me with this.
Thanks very much.
Sherry Chen
|
|
|
|
|
|
Sherry Chen
07/24/2008 8:50 PM
post11043
|
> I am developing qnx drivers that use .so files.
IDE 4.0.1
|
|
|
|
|
|
Elena Laskavaia
07/25/2008 9:31 AM
post11058
|
These message generated by gdb? It does not make much sense.
devn-bcm5691.so - are symbols for it loaded? You check it in Modules view.
When you debug it does debugger knows where to look for symbols for this library?
Sherry Chen wrote:
> I am developing qnx drivers that use .so files.
> Often my debug session does not break on the breakpoints I set up after I sych my source code with perforce. If it
happens, I have to re-import my code and start from scratch. Sometime, it still does not work.
>
> Today I ran two debug configurations, one for io-net, one for io-pkt. Both code uses the same devn-bcm5691.so on the
target system. io-net session would break as I have setup.
>
> I kill the io-net session (debug tab display empty window) and start the io-pkt session. The io-pkt session would not
break. I have stepped through the code and am sure that devn-bcm5691.so was loaded. And yet it does not break and
console display the following messages. The program run through, because my debugging print shows on the screen.
>
> ------------------------------------------
> Cannot remove breakpoints because program is no longer writable.
> It might be running in another process.
> Further execution is probably impossible.
> Cannot remove breakpoints because program is no longer writable.
> It might be running in another process.
> Further execution is probably impossible.
> --------------------------------------------
>
> This scenario can be repeated after I reboot the target system.
>
> I am not sure what the IDE system use to keep the breakpoints or other debug information from session to session. My
guess is these files are locked and not cleared from one debug session to the other.
>
> Please help me with this.
>
> Thanks very much.
> Sherry Chen
>
>
>
>
>
>
>
>
>
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post11040
>
>
|
|
|
|
|
|
Sherry Chen
07/25/2008 1:08 PM
post11089
|
> These message generated by gdb? It does not make much sense.
>
> devn-bcm5691.so - are symbols for it loaded? You check it in Modules view.
> When you debug it does debugger knows where to look for symbols for this
> library?
>
>
I am not sure the message is generated by gdb or not. Those message
was generated after the code loads devnp-shim.so.
I checked the modules view. libc.so.2 and devnp-shim.so do not have subtree.
The devn-bcm5691.so has a tree name libdevn-bcm5691.so. By the way, I have to rename libdevn-bcm5691.so to devn-bcm5691,
so. The io-net -d bcm5691 -p tcpip only accept filename devn-bcm5691.so.
When I use the debugger, the debugger always generate messages as the following, Even the debugger breaks.
No source file named bcm5690_npi.c.
No source file named ......c
This time when it fails to break, the following are generated:
No source file named bcm5690_npi.c.
Error in re-setting breakpoint 14:
No source file named bcm5690.c.
Error in re-setting breakpoint 15:
No source file named bcm5690.c.
I am not sure how the QNX IDE resolve file name and locations and where to look for source code. I try to use dbg
console, but do not know how. help command does not help that much. And a lot of the commands listed in "dbg help" echos
the typed-in comand but does not respond with results. Some do.
I appreciate very very much if this problem can be solved. This slows my development effort significantly. My guess is
that something needs to be reset or cleared but I do not know which one.
|
|
|
|
|
|
Elena Laskavaia
07/25/2008 1:27 PM
post11092
|
Ok debugger looks for libraries in directories specified in Shared
Libraries tab of Debugger tab of launch config.
File name with the library should match EXACTLY the name in binary, i.e.
if it looking for libxxx.so.1 it should be file with name in one the
directories from this list.
If in modules view this library does not have debug symbol near it and
no children - symbols are not loaded, gdb can't find library,
breakpoints and step in won't work for it.
Gdb console - open Console view, click on console selector menu (looks
like monitor) and select one that has gdb in the name (only during
active debug session)
See also debugger FAQ:
http://community.qnx.com/sf/wiki/do/viewPage/projects.ide/wiki/DebuggerFAQ
Sherry Chen wrote:
>> These message generated by gdb? It does not make much sense.
>>
>> devn-bcm5691.so - are symbols for it loaded? You check it in Modules view.
>> When you debug it does debugger knows where to look for symbols for this
>> library?
>>
>>
>>
>
> I am not sure the message is generated by gdb or not. Those message
> was generated after the code loads devnp-shim.so.
>
> I checked the modules view. libc.so.2 and devnp-shim.so do not have subtree.
> The devn-bcm5691.so has a tree name libdevn-bcm5691.so. By the way, I have to rename libdevn-bcm5691.so to devn-
bcm5691,so. The io-net -d bcm5691 -p tcpip only accept filename devn-bcm5691.so.
>
> When I use the debugger, the debugger always generate messages as the following, Even the debugger breaks.
>
> No source file named bcm5690_npi.c.
> No source file named ......c
>
> This time when it fails to break, the following are generated:
> No source file named bcm5690_npi.c.
> Error in re-setting breakpoint 14:
> No source file named bcm5690.c.
> Error in re-setting breakpoint 15:
> No source file named bcm5690.c.
>
> I am not sure how the QNX IDE resolve file name and locations and where to look for source code. I try to use dbg
console, but do not know how. help command does not help that much. And a lot of the commands listed in "dbg help" echos
the typed-in comand but does not respond with results. Some do.
>
> I appreciate very very much if this problem can be solved. This slows my development effort significantly. My guess
is that something needs to be reset or cleared but I do not know which one.
>
>
>
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post11089
>
>
|
|
|
|
|
|
Sherry Chen
07/25/2008 5:16 PM
post11110
|
> Ok debugger looks for libraries in directories specified in Shared
> Libraries tab of Debugger tab of launch config.
> File name with the library should match EXACTLY the name in binary, i.e.
> if it looking for libxxx.so.1 it should be file with name in one the
> directories from this list.
> If in modules view this library does not have debug symbol near it and
> no children - symbols are not loaded, gdb can't find library,
> breakpoints and step in won't work for it.
> Gdb console - open Console view, click on console selector menu (looks
> like monitor) and select one that has gdb in the name (only during
> active debug session)
>
> See also debugger FAQ:
> http://community.qnx.com/sf/wiki/do/viewPage/projects.ide/wiki/DebuggerFAQ
>
I checked my setup. Everything is setup correctly. And the 2nd panel in module view says the symbols are loaded for each
module with the symbols file listed. All the symbole file exists in the directory. For the devnp-shim.so, no children.
For the devn-bcm5691.so, has children. My code works, just it does not break for either module.
Thanks for the FAQ web. They are helpful but not for this problem.
Still my gdb console display the following:
What does the following message mean? (see this message in below)
"Cannot remove breakpoints because program is no longer writable."
Which program?
=====
MsgNak received - resending
attach 880673
No source file named bcm5690_npi.c.
No source file named l3_npi.c.
No source file named bcm5690.c.
No source file named bcm5690.c.
No source file named l4_driver_ip_iopkt.c.
No source file named io-net.c.
Stopped due to shared library event
No source file named bcm5690_npi.c.
No source file named l3_npi.c.
No source file named bcm5690.c.
No source file named bcm5690.c.
No source file named l4_driver_ip_iopkt.c.
No source file named io-net.c.
Stopped due to shared library event
[Switching to process 880673]
Stopped due to shared library event
Stopped due to shared library event
Stopped due to shared library event
Stopped due to shared library event
Stopped due to shared library event
Stopped due to shared library event
Stopped due to shared library event
No source file named l3_npi.c.
No source file named l4_driver_ip_iopkt.c.
No source file named io-net.c.
Stopped due to shared library event
Stopped due to shared library event
Stopped due to shared library event
No source file named l3_npi.c.
No source file named l4_driver_ip_iopkt.c.
No source file named io-net.c.
Stopped due to shared library event
Cannot remove breakpoints because program is no longer writable.
It might be running in another process.
Further execution is probably impossible.
Stopped due to shared library event
Stopped due to shared library event
Error in re-setting breakpoint 13:
Stopped due to shared library event
No source file named bcm5690_npi.c.
Error in re-setting breakpoint 14:
No source file named bcm5690.c.
Error in re-setting breakpoint 15:
No source file named bcm5690.c.
No source file named l3_npi.c.
No source file named l4_driver_ip_iopkt.c.
Stopped due to shared library event
Stopped due to shared library event
Stopped due to shared library event
Stopped due to shared library event
Stopped due to shared library event
No source file named l3_npi.c.
No source file named l4_driver_ip_iopkt.c.
Stopped due to shared library event
Stopped due to shared library event
|
|
|
|
|
|
Elena Laskavaia
07/28/2008 9:57 AM
post11146
|
Just as an experiment when you library is loaded can you get address of
any function from there and put breakpoint by address and see if it hits
it? (From gdb console "p &myfunc" then "b *0x8020304" - address that is
returned)
The message can be generated when library is unloaded and gdb trying to
re-set breakpoints in it, which is contradicts the fact that it never
set them in a first place...
|
|
|
|
|
|
Aleksandar Ristovski(deleted)
|
|
|
Aleksandar Ristovski(deleted)
07/28/2008 10:11 AM
post11147
|
Elena Laskavaia wrote:
> Just as an experiment when you library is loaded can you get address of
> any function from there and put breakpoint by address and see if it hits
> it? (From gdb console "p &myfunc" then "b *0x8020304" - address that is
> returned)
>
In addition, could you also type the following commands and send the results:
info sharedlibrary
maint info breakpoint
Please clarify: does it ever work? Is the issue only when you run one session and then the other? Could you check from
your process explorer (assuming your host is Windows) that when you stop the first session GDB died before you started
another session?
|
|
|
|
|
|
Sherry Chen
07/28/2008 2:38 PM
post11163
|
> Elena Laskavaia wrote:
> > Just as an experiment when you library is loaded can you get address of
> > any function from there and put breakpoint by address and see if it hits
> > it? (From gdb console "p &myfunc" then "b *0x8020304" - address that is
> > returned)
Case I (Switch between io-net config and io-pkt config)
This case, the io-net config works/debugs/breaks with devn-bcm5691.so reliably. When I move from io-net to io-pkt config
, both shim.so and bcm5691.so do not break (works once and I reconfig, it stops working and never work again). And it
generates the error message as listed above.
When I do the switch, the first session always stopped and cleared from the debug panel. At any time, only one debug
session is running.
Case II (Sync with perforce)
For devn-bcm5691.so, after I do a perforce sync, project clean, build), it works sometime, does not work sometime.
When it get stuck, the only way I got it to work is to recreate a project from scratch.
I tried the following with a working debug/break session. (See my another reply, I can not recreate the not working
session now)
info sharedlibrary -> works.
maint info breakpoint ===-> echo command, no additional display.
p &my function ->works.
b *address -> works.
I notices the following:
- After I do a project clean, all .so files are deleted from my binary directory.
- I then rename libdevn-bcm5691.so to devn-bcm5691.so and copy the renamed file to my target side.
- Start debug session, code breaks. The module view displays that libdevn-bcm5691.so.1 is loaded.
- I refresh the project display, the libdevn-bcm5691.so.1 is listed under binary directory.
For io-pkt, the project is imported into IDE, But we do offline make, using the build the procedure provided by QNX.
Then we copied the renamed devnp-shim.so to target LD_LIBRARY_PATH. Since I did not know the module panel display
feature and I did not know a .so.1 file is generated by the debugger. I did not check if .so.1 is cleaned or not. Would
this make a difference?
When the debugger complain that it can not reset breakpoint information, which file does the debugger try to access?
|
|
|
|
|
|
Aleksandar Ristovski(deleted)
|
|
|
Aleksandar Ristovski(deleted)
07/28/2008 2:45 PM
post11164
|
Sherry Chen wrote:
> info sharedlibrary -> works.
> maint info breakpoint ===-> echo command, no additional display.
What I meant is, could you post the results from the instructions above. If you could, post outputs in the io-pkt config
case, both when it works and when it doesn't.
> I did not check if .so.1 is cleaned or not. Would this make a difference?
I think it can make a difference. Please make sure that both copies are removed before transferring the new binaries (by
starting debug session or manually).
Thanks,
Aleksandar
|
|
|
|
|
|
Sherry Chen
07/28/2008 4:21 PM
post11168
|
> Sherry Chen wrote:
> > info sharedlibrary -> works.
> > maint info breakpoint ===-> echo command, no additional display.
>
> What I meant is, could you post the results from the instructions above. If
> you could, post outputs in the io-pkt config case, both when it works and when
> it doesn't.
>
> > I did not check if .so.1 is cleaned or not. Would this make a difference?
>
> I think it can make a difference. Please make sure that both copies are
> removed before transferring the new binaries (by starting debug session or
> manually).
>
> Thanks,
>
> Aleksandar
I am not sure "post output" means. I did not get any output from the
"maint info breakpoint". I got meaningful outputs from other commands.
|
|
|
|
|
|
Aleksandar Ristovski(deleted)
|
|
|
Aleksandar Ristovski(deleted)
07/28/2008 4:28 PM
post11169
|
Sherry Chen wrote:
> I am not sure "post output" means. I did not get any output from the
> "maint info breakpoint". I got meaningful outputs from other commands.
>
I am assuming you can not get any meaningful results since gdb is probably already gone by the time you get a chance to
type the command (in the case of a session with failing breakpoint inserts).
|
|
|
|
|
|
Sherry Chen
07/29/2008 1:45 PM
post11201
|
> Sherry Chen wrote:
> > I am not sure "post output" means. I did not get any output from the
> > "maint info breakpoint". I got meaningful outputs from other commands.
> >
>
> I am assuming you can not get any meaningful results since gdb is probably
> already gone by the time you get a chance to type the command (in the case of
> a session with failing breakpoint inserts).
I shall give a try with a failing case. I am debugging the io-net bcm5691.so now. After I finish this, I will move to io
-pkt+shim bcm569.so debugging, at that time I shall report my results (both a good case and a bad case). This can take a
few days.
Thanks very much for the helpful instructions. I shall use them when I encounter problem.
Regards,
Sherry
|
|
|
|
|
|
Sherry Chen
07/28/2008 1:25 PM
post11160
|
> Just as an experiment when you library is loaded can you get address of
> any function from there and put breakpoint by address and see if it hits
> it? (From gdb console "p &myfunc" then "b *0x8020304" - address that is
> returned)
>
> The message can be generated when library is unloaded and gdb trying to
> re-set breakpoints in it, which is contradicts the fact that it never
> set them in a first place...
Thanks very much for the import tip. Currently I am debugging with no break issues on ah io-net project. I have finished
the io-net project and move this io-net to io-pkt project which I encountered this break problem. I shall reply my test
result when I get to that point.
Regards, Sherry
|
|
|
|
|
|
Sherry Chen
08/01/2008 2:23 PM
post11353
|
I no longer have debug fail to break problem now, when move to io-pkt.
Thanks very much for important tips. They really helped. Now I know what to look when having problem.
|
|
|
|
|
|
