Forums | developer.brewmp.com Forums | developer.brewmp.com

Developer

Forums

I apologize if this information is somewhere in the forums. However, I can't search on 'gdb' as the forum search rejects search arguments that small. (Grrrr....)

Anyway, I'm trying to debug a 1.1 app in the emulator using gcc/gdb. I have no problems building and running my app in the emulator, only debugging.

After building a debug version (i.e., passing -g to compile and link command lines), I do the following in my makefile:

gdb --args $(EMULATOR) -a $(APPDIR) -m $(MIFDIR)

If, as soon as gdb starts, I type run, the emulator runs and shows my app, but if I try to run the app I get:

warning: #*gBI
warning: #*gST=16809984
warning: #*gSU=16809984
warning: #*gCL=16809984
warning: #*gST=3149108325
warning: #*gXX=ALL
warning: #*gEX
warning: #*gCL=3149108325

If instead I type file app.o before run to load the app's symbols, then the emulator won't even run. (This is probably just stupidity on my part, since I think it's trying to run app.o now, instead of just loading symbols from it.)

mattmo wrote:
If instead I type file app.o before run to load the app's symbols, then the emulator won't even run. (This is probably just stupidity on my part, since I think it's trying to run app.o now, instead of just loading symbols from it.)
Ignore that part... I realize that was pretty stupid. Still can't things debugging properly, though, though I've tried various combinations of target exec, symbol-file, and similar.

mattmo wrote:
If instead I type file app.o before run to load the app's symbols, then the emulator won't even run. (This is probably just stupidity on my part, since I think it's trying to run app.o now, instead of just loading symbols from it.)
Ignore that part... I realize that was pretty stupid. Still can't things debugging properly, though, though I've tried various combinations of target exec, symbol-file, and similar.

mattmo wrote:
If, as soon as gdb starts, I type run, the emulator runs and shows my app, but if I try to run the app I get:
****, I am utterly brain dead today. When I actually run the app I think I'm running, it will run in gdb, no problem. Sheesh. Can someone smack me upside the head with a two-by-four?
Okay... at this point I still can't breakpoint. Here's what I'm doing in gdb (run with no command-line arguments in the build directory):
target exec {path to emulator}
set args -m {path to mif-file} -a {path to app-dir}
symbol-file app.o
list AEEClsCreateInstance
Now, at this point, I can see my code for AEEClsCreateInstance, and I can run and see my app run in the emulator. Good. Now, if I try this before I run:
break AEEClsCreateInstance
I get the error:
Cannot access memory at address 0x0
I realize that this isn't really a brew problem; it's most certainly a problem either in my use of gdb or in how I built the .dll/.o files. Any hints on this are also appreciated. Here is how I build my .o files:
gcc -c -DAEE_SIMULATOR -D__int64=long\ long -I/cygdrive/c/BREW_11/inc
-DDEBUG=1 -W -Wall -fshort-enums -fno-builtin -O0 -g -o file.o file.cpp
and building the .dll:
gcc -s -shared -static -nostdlib -g -o app.dll AEEModGen.o AEEAppGen.o file.o

mattmo wrote:
If, as soon as gdb starts, I type run, the emulator runs and shows my app, but if I try to run the app I get:
****, I am utterly brain dead today. When I actually run the app I think I'm running, it will run in gdb, no problem. Sheesh. Can someone smack me upside the head with a two-by-four?
Okay... at this point I still can't breakpoint. Here's what I'm doing in gdb (run with no command-line arguments in the build directory):
target exec {path to emulator}
set args -m {path to mif-file} -a {path to app-dir}
symbol-file app.o
list AEEClsCreateInstance
Now, at this point, I can see my code for AEEClsCreateInstance, and I can run and see my app run in the emulator. Good. Now, if I try this before I run:
break AEEClsCreateInstance
I get the error:
Cannot access memory at address 0x0
I realize that this isn't really a brew problem; it's most certainly a problem either in my use of gdb or in how I built the .dll/.o files. Any hints on this are also appreciated. Here is how I build my .o files:
gcc -c -DAEE_SIMULATOR -D__int64=long\ long -I/cygdrive/c/BREW_11/inc
-DDEBUG=1 -W -Wall -fshort-enums -fno-builtin -O0 -g -o file.o file.cpp
and building the .dll:
gcc -s -shared -static -nostdlib -g -o app.dll AEEModGen.o AEEAppGen.o file.o

at a guess i'd say it had something to do with the way the emulator.exe is built, not your dll.
if you grok asm use http://home.t-online.de/home/Ollydbg/ it should work with the dlls, you might even get symbol info out of it.
or you can use a macro with hardcoded int 3 to make gdb stop where you want it too, not great i know, but if you don't have a good debugger available its 'what you got', then either nop them or add some sort of conditional.
of course theres always softice, which may be a tad overkill ;)

at a guess i'd say it had something to do with the way the emulator.exe is built, not your dll.
if you grok asm use http://home.t-online.de/home/Ollydbg/ it should work with the dlls, you might even get symbol info out of it.
or you can use a macro with hardcoded int 3 to make gdb stop where you want it too, not great i know, but if you don't have a good debugger available its 'what you got', then either nop them or add some sort of conditional.
of course theres always softice, which may be a tad overkill ;)

mattmo wrote:
If, as soon as gdb starts, I type run, the emulator runs and shows my app, but if I try to run the app I get:
warning: #*gBI
warning: #*gST=16809984
warning: #*gSU=16809984
warning: #*gCL=16809984
warning: #*gST=3149108325
warning: #*gXX=ALL
warning: #*gEX
warning: #*gCL=3149108325
I take it that gdb hangs at this point: that the emulator window never comes up and you're stuck.
If so, it might be weirdness with which version of gcc you're using. I had this problem as soon as I upgraded from gcc 2.95 (to, I think, gcc 3.3). I never figured out why this was (sorry I can't be more helpful on that score), but if you try installing gcc 2.95 and rebuilding all of your .o and .dll files, I bet you can get past it.
-Jesse

mattmo wrote:
If, as soon as gdb starts, I type run, the emulator runs and shows my app, but if I try to run the app I get:
warning: #*gBI
warning: #*gST=16809984
warning: #*gSU=16809984
warning: #*gCL=16809984
warning: #*gST=3149108325
warning: #*gXX=ALL
warning: #*gEX
warning: #*gCL=3149108325
I take it that gdb hangs at this point: that the emulator window never comes up and you're stuck.
If so, it might be weirdness with which version of gcc you're using. I had this problem as soon as I upgraded from gcc 2.95 (to, I think, gcc 3.3). I never figured out why this was (sorry I can't be more helpful on that score), but if you try installing gcc 2.95 and rebuilding all of your .o and .dll files, I bet you can get past it.
-Jesse

jhw wrote:I take it that gdb hangs at this point: that the emulator window never comes up and you're stuck.
No, sorry... Look at the other post where I mention how brain dead I am. All the warnings were not actually a problem. I just wasn't running the correct code at the time.
I can run the app fine now in the emulator inside gdb. I just can't set breakpoints.

jhw wrote:I take it that gdb hangs at this point: that the emulator window never comes up and you're stuck.
No, sorry... Look at the other post where I mention how brain dead I am. All the warnings were not actually a problem. I just wasn't running the correct code at the time.
I can run the app fine now in the emulator inside gdb. I just can't set breakpoints.

mattmo wrote:I can run the app fine now in the emulator inside gdb. I just can't set breakpoints.
We may have a problem here. To be honest, I don't typically use the breakpoint feature of gdb, and I don't think I've ever used it with BREW work. I just use it to catch and inspect crash bugs. I use DBGPRINTF for other things (particularly because gdb isn't available on-device anyhow).
So I tried doing it just now. I think we're going to have a problem with the whole .dll thing. Typically, I execute gdb with "file" set to the actual emulator executable, which in turn loads the .dll. When the .dll crashes, gdb inspects the .dll for debugging symbols and feeds me a stack.
So I tried it:
jhw cygwin prompt> gdb c:/BREWsdk2.1.0/bin/BREW_Emulator
GNU gdb 2003-03-03-cvs (cygwin-special)
Copyright 2003 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 "i686-pc-cygwin"...
Minimal symbols from BREW_Emulator.exe...(no debugging symbols found)...
(gdb) break midlet.cpp:65
No symbol table is loaded. Use the "file" command.
(gdb) help file
Use FILE as program to be debugged.
It is read for its symbols, for getting the contents of pure memory,
and it is the program executed when you use the `run' command.
If FILE cannot be found as specified, your execution directory path
($PATH) is searched for a command of that name.
No arg means to have no executable file and no symbols.
(gdb) file myapp.dll
myapp.dll: No such file or directory.
(gdb) file ~/emulator/myapp/myapp.dll
Reading symbols from ~/emulator/myapp/myapp.dll...done.
(gdb) break midlet.cpp:65
Breakpoint 1 at 0x10013fa1: file midlet.cpp, line 65.
(gdb) run
Starting program: /home/jhw/emulator/myapp/myapp.dll
Error creating process /home/jhw/emulator/myapp/myapp.dll, (error 193)
(gdb) quit
jhw cygwin prompt>
It looks like we're caught in a Catch-22. I can't set a breakpoint in the emulator executable because it doesn't have a symbol table of it's own (and it *really* doesn't have *my* symbol table), but I can't set the file to be debugged to my .dll (where my symbol table lives), because it's not an executable.
I'm sure there's a way to do this. Researching further...
-Jesse

mattmo wrote:I can run the app fine now in the emulator inside gdb. I just can't set breakpoints.
We may have a problem here. To be honest, I don't typically use the breakpoint feature of gdb, and I don't think I've ever used it with BREW work. I just use it to catch and inspect crash bugs. I use DBGPRINTF for other things (particularly because gdb isn't available on-device anyhow).
So I tried doing it just now. I think we're going to have a problem with the whole .dll thing. Typically, I execute gdb with "file" set to the actual emulator executable, which in turn loads the .dll. When the .dll crashes, gdb inspects the .dll for debugging symbols and feeds me a stack.
So I tried it:
jhw cygwin prompt> gdb c:/BREWsdk2.1.0/bin/BREW_Emulator
GNU gdb 2003-03-03-cvs (cygwin-special)
Copyright 2003 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 "i686-pc-cygwin"...
Minimal symbols from BREW_Emulator.exe...(no debugging symbols found)...
(gdb) break midlet.cpp:65
No symbol table is loaded. Use the "file" command.
(gdb) help file
Use FILE as program to be debugged.
It is read for its symbols, for getting the contents of pure memory,
and it is the program executed when you use the `run' command.
If FILE cannot be found as specified, your execution directory path
($PATH) is searched for a command of that name.
No arg means to have no executable file and no symbols.
(gdb) file myapp.dll
myapp.dll: No such file or directory.
(gdb) file ~/emulator/myapp/myapp.dll
Reading symbols from ~/emulator/myapp/myapp.dll...done.
(gdb) break midlet.cpp:65
Breakpoint 1 at 0x10013fa1: file midlet.cpp, line 65.
(gdb) run
Starting program: /home/jhw/emulator/myapp/myapp.dll
Error creating process /home/jhw/emulator/myapp/myapp.dll, (error 193)
(gdb) quit
jhw cygwin prompt>
It looks like we're caught in a Catch-22. I can't set a breakpoint in the emulator executable because it doesn't have a symbol table of it's own (and it *really* doesn't have *my* symbol table), but I can't set the file to be debugged to my .dll (where my symbol table lives), because it's not an executable.
I'm sure there's a way to do this. Researching further...
-Jesse

I haven't tried this yet (had to start porting some code and put this aside for the moment), but here's some stuff I'm guessing may be necessary.
You don't want to do file app.dll because that will set the .dll file as the executable as well. More appropriate would be symbol-file app.dll since that loads symbols but doesn't change the executable.
However, my .dll is small -- very small. The .o files contain debug info (as I can see if I say symbol-file app.dll followed by list AEEClsCreateInstance for example), but the .dll does not. gdb will tell you that there are no debug symbols in the .dll if you try symbol-file app.dll. I suspect there is someway to load up the .dll file with debug info during build (I have seen someone else mention it), but I don't know how to do it.
There seems like there may be another way. If you add -Xlinker -M to the link command, it should generate a map to standard output. This includes addresses of where various symbols are expected to be. (?) Then, gdb has a command add-symbol-file FILE ADDR (some other options also available) so you can tell where to load the symbols. I think using that appropriately might do the trick, but I haven't tried it yet.

I haven't tried this yet (had to start porting some code and put this aside for the moment), but here's some stuff I'm guessing may be necessary.
You don't want to do file app.dll because that will set the .dll file as the executable as well. More appropriate would be symbol-file app.dll since that loads symbols but doesn't change the executable.
However, my .dll is small -- very small. The .o files contain debug info (as I can see if I say symbol-file app.dll followed by list AEEClsCreateInstance for example), but the .dll does not. gdb will tell you that there are no debug symbols in the .dll if you try symbol-file app.dll. I suspect there is someway to load up the .dll file with debug info during build (I have seen someone else mention it), but I don't know how to do it.
There seems like there may be another way. If you add -Xlinker -M to the link command, it should generate a map to standard output. This includes addresses of where various symbols are expected to be. (?) Then, gdb has a command add-symbol-file FILE ADDR (some other options also available) so you can tell where to load the symbols. I think using that appropriately might do the trick, but I haven't tried it yet.

mattmo wrote:However, my .dll is small -- very small. The .o files contain debug info (as I can see if I say symbol-file app.dll followed by list AEEClsCreateInstance for example), but the .dll does not. gdb will tell you that there are no debug symbols in the .dll if you try symbol-file app.dll. I suspect there is someway to load up the .dll file with debug info during build (I have seen someone else mention it), but I don't know how to do it.
I use the flag -ggdb when I compile. Whenever I crash in my .dll I get rich gdb features: backtrace works ok, and so does up, down, and display. I'm just stuck on breakpoints and I've been trying symbol-file and dll-symbols, with no success.
[jhw ~/myapp]$ make gdb
make BUILD=LUXURY COMPILER=GNUDLL gnu.dll/LUXURY/myapp.dll
make[1]: Entering directory `/home/jhw/myapp'
make[1]: `gnu.dll/LUXURY/myapp.dll' is up to date.
make[1]: Leaving directory `/home/jhw/myapp
cp -f LUXURY/myapp.mif /home/jhw/emulator
cp -f gnu.dll/LUXURY/myapp.dll /home/jhw/emulator/myapp
cp -f LUXURY/myapp.bar /home/jhw/emulator/myapp
gdb c:/BREWsdk2.1.0/bin/BREW_Emulator
GNU gdb 2003-03-03-cvs (cygwin-special)
Copyright 2003 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 "i686-pc-cygwin"...
Minimal symbols from BREW_Emulator.exe...(no debugging symbols found)...
(gdb) dll-symbols ~/emulator/myapp/myapp.dll
(gdb) break midlet.cpp:65
Breakpoint 1 at 0x10013fa1: file midlet.cpp, line 65.
(gdb) info break
Num Type Disp Enb Address What
1 breakpoint keep y 0x10013fa1 in MIDlet::construct(System&) at midlet.c
pp:65
(gdb) quit
[jhw ~/myapp]$
So everything looks like the breakpoint is alive and well, but when I run it just runs right over the breakpoint like it wasn't there. I've also tried various permutations of add-sym and symbol-file, with the same negative results.
-Jesse

mattmo wrote:However, my .dll is small -- very small. The .o files contain debug info (as I can see if I say symbol-file app.dll followed by list AEEClsCreateInstance for example), but the .dll does not. gdb will tell you that there are no debug symbols in the .dll if you try symbol-file app.dll. I suspect there is someway to load up the .dll file with debug info during build (I have seen someone else mention it), but I don't know how to do it.
I use the flag -ggdb when I compile. Whenever I crash in my .dll I get rich gdb features: backtrace works ok, and so does up, down, and display. I'm just stuck on breakpoints and I've been trying symbol-file and dll-symbols, with no success.
[jhw ~/myapp]$ make gdb
make BUILD=LUXURY COMPILER=GNUDLL gnu.dll/LUXURY/myapp.dll
make[1]: Entering directory `/home/jhw/myapp'
make[1]: `gnu.dll/LUXURY/myapp.dll' is up to date.
make[1]: Leaving directory `/home/jhw/myapp
cp -f LUXURY/myapp.mif /home/jhw/emulator
cp -f gnu.dll/LUXURY/myapp.dll /home/jhw/emulator/myapp
cp -f LUXURY/myapp.bar /home/jhw/emulator/myapp
gdb c:/BREWsdk2.1.0/bin/BREW_Emulator
GNU gdb 2003-03-03-cvs (cygwin-special)
Copyright 2003 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 "i686-pc-cygwin"...
Minimal symbols from BREW_Emulator.exe...(no debugging symbols found)...
(gdb) dll-symbols ~/emulator/myapp/myapp.dll
(gdb) break midlet.cpp:65
Breakpoint 1 at 0x10013fa1: file midlet.cpp, line 65.
(gdb) info break
Num Type Disp Enb Address What
1 breakpoint keep y 0x10013fa1 in MIDlet::construct(System&) at midlet.c
pp:65
(gdb) quit
[jhw ~/myapp]$
So everything looks like the breakpoint is alive and well, but when I run it just runs right over the breakpoint like it wasn't there. I've also tried various permutations of add-sym and symbol-file, with the same negative results.
-Jesse

try hard coding a int 3 at the initialization of the code, so in EVT_APP_START then running the emulator inside gdb , select the app, it should hit the breakpoint, then set the other test breakpoint with gdb and run it.
this will tell you two things, one that gdb is working and is the current int 3 handler, and two that there maybe some relocation going on after the emulator loads the dll.

try hard coding a int 3 at the initialization of the code, so in EVT_APP_START then running the emulator inside gdb , select the app, it should hit the breakpoint, then set the other test breakpoint with gdb and run it.
this will tell you two things, one that gdb is working and is the current int 3 handler, and two that there maybe some relocation going on after the emulator loads the dll.

Any particular reason you use GDB? Why not use MS Visual Stuff? On the emulator end, that's the best approach.
mattmo wrote:I apologize if this information is somewhere in the forums. However, I can't search on 'gdb' as the forum search rejects search arguments that small. (Grrrr....)
Anyway, I'm trying to debug a 1.1 app in the emulator using gcc/gdb. I have no problems building and running my app in the emulator, only debugging.
After building a debug version (i.e., passing -g to compile and link command lines), I do the following in my makefile:
gdb --args $(EMULATOR) -a $(APPDIR) -m $(MIFDIR)
If, as soon as gdb starts, I type run, the emulator runs and shows my app, but if I try to run the app I get:
warning: #*gBI
warning: #*gST=16809984
warning: #*gSU=16809984
warning: #*gCL=16809984
warning: #*gST=3149108325
warning: #*gXX=ALL
warning: #*gEX
warning: #*gCL=3149108325
If instead I type file app.o before run to load the app's symbols, then the emulator won't even run. (This is probably just stupidity on my part, since I think it's trying to run app.o now, instead of just loading symbols from it.)

Any particular reason you use GDB? Why not use MS Visual Stuff? On the emulator end, that's the best approach.
mattmo wrote:I apologize if this information is somewhere in the forums. However, I can't search on 'gdb' as the forum search rejects search arguments that small. (Grrrr....)
Anyway, I'm trying to debug a 1.1 app in the emulator using gcc/gdb. I have no problems building and running my app in the emulator, only debugging.
After building a debug version (i.e., passing -g to compile and link command lines), I do the following in my makefile:
gdb --args $(EMULATOR) -a $(APPDIR) -m $(MIFDIR)
If, as soon as gdb starts, I type run, the emulator runs and shows my app, but if I try to run the app I get:
warning: #*gBI
warning: #*gST=16809984
warning: #*gSU=16809984
warning: #*gCL=16809984
warning: #*gST=3149108325
warning: #*gXX=ALL
warning: #*gEX
warning: #*gCL=3149108325
If instead I type file app.o before run to load the app's symbols, then the emulator won't even run. (This is probably just stupidity on my part, since I think it's trying to run app.o now, instead of just loading symbols from it.)

accolade wrote:Any particular reason you use GDB? Why not use MS Visual Stuff? On the emulator end, that's the best approach.
Any particular reason? Yes.
But I have no intention of starting/getting into a platform war, so I'll leave it at that.

accolade wrote:Any particular reason you use GDB? Why not use MS Visual Stuff? On the emulator end, that's the best approach.
Any particular reason? Yes.
But I have no intention of starting/getting into a platform war, so I'll leave it at that.

jhw wrote:So everything looks like the breakpoint is alive and well, but when I run it just runs right over the breakpoint like it wasn't there. I've also tried various permutations of add-sym and symbol-file, with the same negative results.
I made another attempt and got some similar results. My last attempt seemed a bit better, but just isn't quite there yet. Here's what I did:
gcc -shared -nostdlib -ggdb -Wl,--export-all-symbols -o app.dll AEEModGen.o AEEAppGen.o app.o
gdb --args /cygdrive/c/BREW_11/bin/BREW_Emulator.exe -a {appdir} -m {mifdir}
GNU gdb 2003-09-20-cvs (cygwin-special)
Copyright 2003 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 "i686-pc-cygwin"...(no debugging symbols found)...
(gdb) dll-symbols app.dll
(gdb) break app.cpp:16
Breakpoint 1 at 0x100015df: file app.cpp, line 16.
(gdb) run
Starting program: /cygdrive/c/BREW_11/bin/BREW_Emulator.exe -a {appdir} -m {mifdir}
warning:
warning: #*gBI
Breakpoint 1, AEEClsCreateInstance (ClsId=9656352, pIShell=0x12f2d0, pMod=0x12f2c4, ppObj=0x934b18) at app.cpp:16
16 if (AEECLSID_MYAPP == ClsId) {
Current language: auto; currently c++
(gdb)
Previously I had the -s option in my link line which strips symbols. Once I removed than, my DLL grew in size. Now, if I do 'info functions' after 'dll-symbols', I can see all the symbols, 'list' them.... I still get the 'cannot access memory' error if I try to set a breakpoint by the function name.
When I set the breakpoint at app.cpp:16 (which is just inside my AEEClsCreateInstance function), and 'run', the app stops at that breakpoint. Whether that breakpoint is where I think it is, I'm not sure about that, since the first line of that function is *ppObj = 0; but gdb doesn't think *ppObj is zero.
Once I hit that first breakpoint, I can set breakpoints by function name (ie, 'break moveCursor()'). However, I just get a segfault if I try to continue. So this still isn't the right answer. Maybe a step forward tho...

jhw wrote:So everything looks like the breakpoint is alive and well, but when I run it just runs right over the breakpoint like it wasn't there. I've also tried various permutations of add-sym and symbol-file, with the same negative results.
I made another attempt and got some similar results. My last attempt seemed a bit better, but just isn't quite there yet. Here's what I did:
gcc -shared -nostdlib -ggdb -Wl,--export-all-symbols -o app.dll AEEModGen.o AEEAppGen.o app.o
gdb --args /cygdrive/c/BREW_11/bin/BREW_Emulator.exe -a {appdir} -m {mifdir}
GNU gdb 2003-09-20-cvs (cygwin-special)
Copyright 2003 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 "i686-pc-cygwin"...(no debugging symbols found)...
(gdb) dll-symbols app.dll
(gdb) break app.cpp:16
Breakpoint 1 at 0x100015df: file app.cpp, line 16.
(gdb) run
Starting program: /cygdrive/c/BREW_11/bin/BREW_Emulator.exe -a {appdir} -m {mifdir}
warning:
warning: #*gBI
Breakpoint 1, AEEClsCreateInstance (ClsId=9656352, pIShell=0x12f2d0, pMod=0x12f2c4, ppObj=0x934b18) at app.cpp:16
16 if (AEECLSID_MYAPP == ClsId) {
Current language: auto; currently c++
(gdb)
Previously I had the -s option in my link line which strips symbols. Once I removed than, my DLL grew in size. Now, if I do 'info functions' after 'dll-symbols', I can see all the symbols, 'list' them.... I still get the 'cannot access memory' error if I try to set a breakpoint by the function name.
When I set the breakpoint at app.cpp:16 (which is just inside my AEEClsCreateInstance function), and 'run', the app stops at that breakpoint. Whether that breakpoint is where I think it is, I'm not sure about that, since the first line of that function is *ppObj = 0; but gdb doesn't think *ppObj is zero.
Once I hit that first breakpoint, I can set breakpoints by function name (ie, 'break moveCursor()'). However, I just get a segfault if I try to continue. So this still isn't the right answer. Maybe a step forward tho...

mattmo wrote:
Previously I had the -s option in my link line which strips symbols. Once I removed than, my DLL grew in size. Now, if I do 'info functions' after 'dll-symbols', I can see all the symbols, 'list' them.... I still get the 'cannot access memory' error if I try to set a breakpoint by the function name.
When I set the breakpoint at app.cpp:16 (which is just inside my AEEClsCreateInstance function), and 'run', the app stops at that breakpoint. Whether that breakpoint is where I think it is, I'm not sure about that, since the first line of that function is *ppObj = 0; but gdb doesn't think *ppObj is zero.
Once I hit that first breakpoint, I can set breakpoints by function name (ie, 'break moveCursor()'). However, I just get a segfault if I try to continue. So this still isn't the right answer. Maybe a step forward tho...
I habitually use -ggdb for symbols when I compile .o files. I end up with .dlls of like 2.5 MB! When I get ready to ship, I relink the .dlls with the --strip-debug flag, which brings them down to a more reasonable 0.5 MB.
You've gotten farther than I have, getting gdb to even stop on a specified breakpoint in your code. I'll try following your example right now...
No dice. It just plain won't stop. There's got to be something simple that we're overlooking.
-Jesse

mattmo wrote:
Previously I had the -s option in my link line which strips symbols. Once I removed than, my DLL grew in size. Now, if I do 'info functions' after 'dll-symbols', I can see all the symbols, 'list' them.... I still get the 'cannot access memory' error if I try to set a breakpoint by the function name.
When I set the breakpoint at app.cpp:16 (which is just inside my AEEClsCreateInstance function), and 'run', the app stops at that breakpoint. Whether that breakpoint is where I think it is, I'm not sure about that, since the first line of that function is *ppObj = 0; but gdb doesn't think *ppObj is zero.
Once I hit that first breakpoint, I can set breakpoints by function name (ie, 'break moveCursor()'). However, I just get a segfault if I try to continue. So this still isn't the right answer. Maybe a step forward tho...
I habitually use -ggdb for symbols when I compile .o files. I end up with .dlls of like 2.5 MB! When I get ready to ship, I relink the .dlls with the --strip-debug flag, which brings them down to a more reasonable 0.5 MB.
You've gotten farther than I have, getting gdb to even stop on a specified breakpoint in your code. I'll try following your example right now...
No dice. It just plain won't stop. There's got to be something simple that we're overlooking.
-Jesse