Multi-segment debugging with PRC-tools, it can be done!
I posted a message to the prc-tools-devel mailing list at sourceforge with a description and the patches needed to get multi segment debugging working with prc-tools (gcc/gdb). Look at the prc-tools-devel mailing list archive at http://sourceforge.net/mail/?group_id=4429. Ton van Overbeek, [EMAIL PROTECTED] -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/tech/support/forums/
Who is supporting prc-tools at Palm now ?
After reading the tools-forum it seems that John Marshall is no longer at Palm. Since the web-site still states that prc-tools are officially supported by Palm I am wondering who is going to take over, if anybody at all. With all the recent changes to developer support (my interpretation is that Palm is outsourcing all of it) I do not have very high hopes of Palm continuing support for prc-tools. I hope somebody can prove me wrong Comments (official or unofficial) anybody ? Ton van Overbeek -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/tech/support/forums/
Multi-Segment debugging with GDB, Take 2
The patch + (link to) binaries I posted a few days ago still had a minor problem: The sorting routine used in re-sorting the block vector after relocation had two wrong comparisons for the case of comparing blocks with the same start address. A symptom of this mistake is that under certain circumstances local variables do not show up in GDB. That's what you get when making a last minute change without proper testing A fixed version of the patch is now available at: http://www.tvoverbe.cistron.nl/mseggdbpatch.zip (7436 bytes). Also fixed binaries are available at: http://www.tvoverbe.cistron.nl/mseggdb.zip (926809 bytes). Regards, Ton van Overbeek -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/tech/support/forums/
Re: Makefiles, new pilrc and new build-prc one LAST time
Sally McBride wrote: > > John, > I posted something to the prc-tools-devel list about > the problem(s), so I did not go into depth here. > > But bascially I started with a fresh install (i.e. no > cygwin at all) and followed the release notes for a > windows install at: > > http://sourceforge.net/project/shownotes.php?release_id=31764 > > Then I compiled and installed pilrc-2.8p5 > > the massaging that I needed (there were other things > that I thought I had to do, but ended up not needing) > was to make a "empty" libm.a > > The linker was trying to link it in and since it > didn't exist, I got an error. > I fixed this by donig the follwing: > echo "!\n" > /usr/m68k-palmos/lib/libm.a > > and everything works now with old makefiles > I followed (and participated) in the thread on prc-tools-devel at sourceforge. The problem Sally ran into turns out to be some missing symbolic links in prc-tools-2.0.92-cygwin.tar.gz. In /usr/m68k-palmos/lib the symbolic link from libm.a to libmf.a is missing. The commands for creating the link are in the source for prc-tools-2.0.92 (No change from 2.0.91). The same is true for /usr/m68k-palmos/include/math.h. The symbolic link to mathf.h is missing. The build procedure builds only a single precision floating point math library. Hence the f at the end of the names. Maybe John can update the prc-tools-2.0.92-cygwin.tar.gz file to include these symbolic links. Maybe there are more links missing. Regards, Ton van Overbeek -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/tech/support/forums/
Missing symlinks in prc-tools-2.0.92-cygwin.tar.gz
John Marshall wrote: > [Ton] > > The problem Sally ran into turns out to be > > some missing symbolic links in prc-tools-2.0.92-cygwin.tar.gz. > [...] > > Maybe John can update the prc-tools-2.0.92-cygwin.tar.gz file > > to include these symbolic links. Maybe there are more links missing. > > There's about half a dozen. The problem is that I generated the > distribution against Cygwin 1.1 a week before Cygwin 1.3 was released. > Cygwin 1.3 implements symlinks in terms of Windows shortcuts (good), but > it seems it doesn't understand its own older link format (bad!). > > So folks might want to use Cygwin 1.1.x until the distribution gets > built against Cygwin 1.3... but it might be difficult to find. > Not a great state of affairs. :-( Just some additional information. When listing the contents of prc-tools-2.0.92-cygwin.tar.gz with both version 1.1.8 and 1.3.2 of cygwin1.dll the symlinks for libm.a and math.h discussed in the thread 'Makefiles, new pilrc and new build-prc one LAST time' are missing. However the following symlinks are there with both versions 1.1.8 and 1.3.2 of cygwin1.dll (on a Win98SE system): -- usr/bin/m68k-palmos-cpp.exe link to usr/bin/m68k-palmos-c++.exe usr/bin/m68k-palmos-g++.exe link to usr/bin/m68k-palmos-c++.exe usr/bin/m68k-palmos-gcc.exe link to usr/bin/m68k-palmos-c++.exe usr/bin/m68k-palmos-sdkfind.exe link to usr/bin/m68k-palmos-c++.exe usr/bin/multigen.exe link to usr/bin/m68k-palmos-multigen.exe usr/bin/obj-res.exe link to usr/bin/m68k-palmos-obj-res.exe usr/bin/stubgen.exe link to usr/bin/m68k-palmos-stubgen.exe usr/m68k-palmos/bin/ar.exe link to usr/bin/m68k-palmos-ar.exe usr/m68k-palmos/bin/as.exe link to usr/bin/m68k-palmos-as.exe usr/m68k-palmos/bin/gcc.exe link to usr/bin/m68k-palmos-c++.exe usr/m68k-palmos/bin/ld.exe link to usr/bin/m68k-palmos-ld.exe usr/m68k-palmos/bin/multigen.exe link to usr/bin/m68k-palmos-multigen.exe usr/m68k-palmos/bin/nm.exe link to usr/bin/m68k-palmos-nm.exe usr/m68k-palmos/bin/obj-res.exe link to usr/bin/m68k-palmos-obj-res.exe usr/m68k-palmos/bin/ranlib.exe link to usr/bin/m68k-palmos-ranlib.exe usr/m68k-palmos/bin/sdkfind.exe link to usr/bin/m68k-palmos-c++.exe usr/m68k-palmos/bin/strip.exe link to usr/bin/m68k-palmos-strip.exe usr/m68k-palmos/bin/stubgen.exe link to usr/bin/m68k-palmos-stubgen.exe usr/m68k-palmos/real-bin/g++.exe link to usr/m68k-palmos/real-bin/c++.exe --- So my guess is that there might be a problem with the build script and/or configure/Makefile generation for the libm directory for cygwin. If I find out some more I'll let you know. Ton van Overbeek -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/tech/support/forums/
Re: J. Marshall: New Multiapp..
The Armadillo With The Mask wrote: > > Joe Siebenmann wrote: > > John / PRC-Tools people, > > > > Could you please think about replacing your 'multiapp' multiple code section > > example? It's a "toy" program, and a more "realistic" example app would > > help people through multiple code section problems much better. > > Joe, > Go download and check out "EasyCalc". It's a full-featured app that > uses multiple code segments and the source is included. It helped > me get over the hump. I forget where I got it from though. > Try EuroCool or Tucows. The "right" reference for EasyCalc is http://sourceforge.net/projects/easycalc. >From the project page you can go to the CVS archive for the up-to-date source or to the download page with among other thing the source of all released versions. Source includes Makefile and builds fine on both Linux and Windows prc-tools. Ton van Overbeek -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/tech/support/forums/
Multi-Segment Debugging Patches for prc-tools-2.1
John Marshall has released prc-tools-2.1 today (Thanks John). I have been updating my multi-segment debugging patches during the last few days using prc-tools RC3. Since there is no change in the areas of interest for multi-segment debugging between RC3 and 2.1 I am also releasing an update on my patches. You'll find the details on http://www.tvoverbe.cistron.nl/mseggdb/ReadMe.html. The original patches for prc-tools-2.0.91 are no longer available. The work has been done on Cygwin, but the patches should also work under Linux, Solaris, etc. Enjoy. Ton van Overbeek -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Glib problems
On 2005-02-26, Garth Wimbush <[EMAIL PROTECTED]> wrote:
> Hi,
> I am having trouble with GLibs. The library and source code compiles
> fine, but when I try & run the app it falls over in GLibDispatch when
> trying to call the Glib, under the emulator.
> I version 5r3 of the SDK, and am compiling in a GCC Linux environment.
> My makefile output for the GLib library is as follows:
>
> m68k-palmos-gcc -g -IDevelopment/Palm/include -c
> Development/Palm/ADB/ADB.c -o Development/Palm/ADB/obj/ADB.o
> ctags -f Development/Palm/tags/ADB.tags Development/Palm/ADB/ADB.c
> m68k-palmos-ar rs Development/Palm/lib/libADB.a
> Development/Palm/ADB/obj/ADB.o
> echo "glib { ADB RKAD }" > Development/Palm/ADB/obj/ADB.def
> echo export { `m68k-palmos-nm Development/Palm/lib/libADB.a | grep ' T '
>| cut -c12- | tr "\n" " "` } >>Development/Palm/ADB/obj/ADB.def
> cd Development/Palm/ADB/obj; m68k-palmos-stubgen
> Development/Palm/ADB/obj/ADB.def
> m68k-palmos-gcc -shared -mown-gp -o Development/Palm/ADB/bin/ADBLib
> Development/Palm/ADB/obj/ADB-jumps.s Development/Palm/lib/libADB.a
> build-prc -o Development/Palm/ADB/bin/ADBLib.prc
> Development/Palm/ADB/obj/ADB.def Development/Palm/ADB/bin/ADBLib
> m68k-palmos-gcc -g -c Development/Palm/ADB/obj/ADB-stubs.c -o
> Development/Palm/ADB/obj/ADB-stubs.o
> m68k-palmos-ar rcs Development/Palm/lib/libADB.sa
> Development/Palm/ADB/obj/ADB-stubs.o
>
> This is the GDB output:
> Program received signal SIGTRAP, Trace/breakpoint trap.
> 0x00050a22 in GLibDispatch () at palmos_GLib.c:128
> 128 palmos_GLib.c: No such file or directory.
> in palmos_GLib.c
> (gdb)
>
> Here is a disassembly around the failure, which occurs at
> GLibDispatch+2:
>
> 0x50a20 : moveal %a1@,%a0
> 0x50a22 : cmpal #0,%a0
> 0x50a28 : bnes 0x50a40
> 0x50a2a : movel %a1,[EMAIL PROTECTED]
> 0x50a2c : movel %d0,[EMAIL PROTECTED]
> 0x50a2e : movel %d2,[EMAIL PROTECTED]
> 0x50a30 : movel %d1,[EMAIL PROTECTED]
> 0x50a32 : bsrw 0x50826
> 0x50a36 : lea %sp@(8),%sp
> 0x50a3a : movel [EMAIL PROTECTED],%d0
> 0x50a3c : moveal [EMAIL PROTECTED],%a1
> 0x50a3e : movel %a0,%a1@
> 0x50a40 : moveal %a0@(4),%a1
> 0x50a44 : movel %a0,[EMAIL PROTECTED]
> 0x50a46 : movel %d0,[EMAIL PROTECTED]
> 0x50a48 : moveal %a1@,%a1
> 0x50a4a : jmp %a1@
> 0x50a4c : unlk %fp
> 0x50a4e : rts
>
> Logfile output:
> 58.502: === WARNING:
>
> 58.502: === WARNING: Rocklog (unknown version) just read from memory
> location 0x2EC4, which is in the "displayWidthV
> 20" field of the form starting at 0x2EC4.
>
> The data at this memory location is owned by the Form Manager.
> Applications should not access the data directly. Instead
> , they should make the appropriate Form Manager calls.
> 58.502: === WARNING:
>
> Log_0012.txt lines 20238-20252/20252 (END)
>
> I am guessing that the jumps table has been corrupted in some way, but I
> am at a bit of a loss to know what to do now.
> Has anyone seen similar problems?
I am not experienced in Glibs, but if I remember correctly all data
references should be A4 relative and not A5 relative as in normal code.
In your m68k-palmos-gcc compilation you do not have the -mown-gp (own
global pointer) switch, so my guess is that this is the cause of your
problems. See the prc-tools documentation for more details.
HTH
Ton van Overbeek
--
For information on using the Palm Developer Forums, or to unsubscribe, please
see http://www.palmos.com/dev/support/forums/
Re: Help with a compiler error w/respect to sections in PDS ...
On 2005-03-02, Chris Olson <[EMAIL PROTECTED]> wrote:
> What does this mean in PODS and how do I fix it?
>
> section attribute not allowed for `double blah(double, double)'
>
> The functions all look like this:
>
> #define SECTION __attribute__ ((section (myfns)))
Section names have to be enclosed in quotation marks.
So the above should be
#define SECTION __attribute__ ((section ("myfns")))
See section 4.23 about attribute syntax in the gcc-2.95.3 docs.
(http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC84)
>
> double blah(double a, double b) SECTION;
>
> Chris Olson
>
> PS. I'm new to the GNU tool chain (actually, its just been a LONG
> time ...) on the palm, and I've read the docs, and scoured the archives
> (which are really tough to search by-the-way, at least for the issues
> I've been having ...
>
> PSS. As a matter of fact, I got this style from the PRC docs web-site...
>
> PSSS. I've got a valid sections.def set up already ...
>
HTH
Ton van Overbeek
--
For information on using the Palm Developer Forums, or to unsubscribe, please
see http://www.palmos.com/dev/support/forums/
Re: Multisegment code app built "ok", but it doesn't start ok
On 2005-03-15, Goran Todorovic <[EMAIL PROTECTED]> wrote: > Thanks, Bob! > > I have several tens of functions in the app, among them only four assigned > for the new code segment (one form's event handler + three functions used by > the handler). > > So PilotMain() should be inside code#0 segment? > > Thanks, > Goran > Just to be a bit pedantic ... PilotMain is in the code#1 resource of the prc. If you analyse a prc with PRC-Explorer you see there is always a small code#0 resource which contains stack size preference, etc. In fact it is a leftover from the original Macintosh resource model used in PalmOS. In terms of prc-tools. PilotMain should be in the 'normal' segment (.text), *not* in one fo the sections declared in the .def file. Ton van Overbeek -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: fatal exception from multiplication in gcc compiled callback
On 2005-04-05, Greg Sepesi <[EMAIL PROTECTED]> wrote:
> I'd like to implement a UInt32 x UInt32 multiply (discarding the most
> significant 32 bits of result) in a callback for a sound stream, but the
> multiplication is causing a fatal exception (on a Zire 31). From
> looking at the assembly language produced by gcc, the reason for the
> exception appears to be the attempted use of a global (not available in
> callback).
>
> Here's the applicable data structure and code:
>
> typedef struct PeckAudioType {
>SndStreamRef streamRef;
>UInt32 fileSize;
>UInt32 fileOffset;
>FileRef fileRef;
>UInt32 bufferCount;
>
>UInt32 s;
>UInt32 a;
>UInt32 b;
> } PeckAudioType;
>
> Err CallbackPeckAudio(void *pUserData,
>SndStreamRef stream,
>void *bufferP,
>UInt32 frameCount)
> {
>PeckAudioType *pPeckAudio = (PeckAudioType *)pUserData;
>Err err;
>
>/* Read next sound stream buffer from file. */
>err = VFSFileRead(pPeckAudio->fileRef, frameCount*2, bufferP, NULL);
>
>pPeckAudio->a *= pPeckAudio->b; /* LINE 8 */
>
> - - -
>
> The assembly language for Line 8 is:
>
> .globl CallbackPeckAudio
> CallbackPeckAudio:
> ...
> .ln 8
> move.l [EMAIL PROTECTED](%a5),%a0
> add.l #__mulsi3,%a0 /*JANE2*/
> move.l 28(%a2),-(%sp)
> move.l 24(%a2),-(%sp)
> jsr (%a0)
> addq.l #8,%sp
> move.l %d0,24(%a2)
>
> - - -
>
> Noting that changing the multiplication to addition causes an in-line
> calculation and allows the sound stream callback to work properly, I
> tried gcc's inline assembly.
>
> Err CallbackPeckAudio(void *pUserData,
>SndStreamRef stream,
>void *bufferP,
>UInt32 frameCount)
> {
>PeckAudioType *pPeckAudio = (PeckAudioType *)pUserData;
>Err err;
>
>/* Read next sound stream buffer from file. */
>err = VFSFileRead(pPeckAudio->fileRef, frameCount*2, bufferP, NULL);
>
> // pPeckAudio->a *= pPeckAudio->b;
>__asm__("
> move.l 28(%a2),%d0;
> mulu.l 24(%a2),%d0;
> move.l %d0,24(%a2);
>");
>
> - - -
>
> However, that results in the compiler error: "invalid instruction for
> this architecture; needs 68020 or 68030 or 68040 or 68060 or cpu32 or
> 5200 or 5206e or 5307 or 5407 -- statement `mulu.l 24(%a2),%d0'
> ignored". That's a bit confusing because the MC68EZ328 User Manual
> lists a mulu instruction in its EC000 instruction set. I've never had
> to mess much with the prc-tools. Do I need to somewhere specify that I
> want gcc to produce MC68EZ328 instructions?
>
> Before I get into this any deeper, I'd like to ask how others have
> implemented multiplications from within callbacks.
>
> Thanks,
> Greg
>
The assembler in the m68k-palmos-gcc backend defaults to the bare-bones
m68000 instruction set. You can see this if you do 'm68k-palmos-gcc
-dumpspecs'.
As a workaround use the '-Wa,-m68020' option to force the assembler to
recognize the mulu.l instruction.
HTH
Ton van Overbeek
--
For information on using the Palm Developer Forums, or to unsubscribe, please
see http://www.palmos.com/dev/support/forums/
Re: Where is the Tungsten E simulator?
On 2005-04-09, Dr. Vesselin Bontchev <[EMAIL PROTECTED]> wrote: > Hello folks, > > Could somebody post the directions how to locate the Tungsten E simulator > on the PalmSource Web site? I know that it exists, because I have > downloaded it in the past and have installed it on one of my computers. > Now I want to install it on another - and can't manage to locate it. :-( > I found various generic Garnet simulators - but I remember quite well that > there was one specific for Tungsten E. > Short answer: Nobodyi can. It is not on the PalmSource site but on the PluggedIn PalmOne site. See below. > I'm not asking for an URL, because the simulators are behind the developer > login - I am asking someone to describe how to find the Tungsten E > simulator once I have logged in. > Log in to the PluggedIn site http://pluggedin.palmone.com. Once you are logged in select 'development resources' -> Tungsten on the left hand side. In the search criteria select: Device: Tungsten, Resource Type: Simulators, Date: Any. You will find the TungstenE simulator there (TungstenE.zip May 21, 2004). HTH Ton van Overbeek -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Displaying an alert on sysAppLaunchCmdSyncNotify
On 2005-04-12, Dr. Vesselin Bontchev <[EMAIL PROTECTED]> wrote:
> Hello folks,
>
> I am trying to test the conjecture that the Emulator and the Simulators don't
> send a sysAppLaunchCmdSyncNotify launch code when an application is installed
> on them via drag-n-drop. For this purpose, I have written the following small
> application:
>
> #include
> #include "OnLoad.h"
>
> UInt32 PilotMain (UInt16 cmd, void *cmdPBP, UInt16 launchFlags)
> {
> switch (cmd)
> {
> case sysAppLaunchCmdSyncNotify:
> FrmAlert (kMyAlert);
> break;
> default:
> break;
> }
> return 0;
> }
>
> Indeed, when this application is drag-n-dropped onto the Emulator or any of
> the Simulators, nothing happens. However, a complete test would involve
> verifying that the alert *is* displayed on the real device.
> Unfortunately, when I try to put the above application on a real device
> (Tungsten E, running PalmOS 5.2.1), the HotSync process hangs at the end
> (when the "Cleaning up" message is displayed) and I have to reset the
> device. No alert is displayed.
>
> Can somebody figure out what the problem is? Is it allowed to display
> alerts, despite that another application (the HotSync application) is
> still running?
>
> BTW, if I also add the
>
> case sysAppLaunchCmdNormalLaunch:
>
> line just above the
>
> case sysAppLaunchCmdSyncNotify:
>
> line, the alert *is* displayed when the application is launched.
>
> Regards,
> Vesselin
Look at how this is solved in the DotDotTwo application.
Search for dotdottwo on http://kb.palmsource.com.
When it handles the sysNotifyResetFinishedEvent it only sets an alarm.
It then displays when the alarm triggers.
My guess is that the end of hotsync behaves similar, i.e. no UI available.
HTH
Ton van Overbeek
--
For information on using the Palm Developer Forums, or to unsubscribe, please
see http://www.palmos.com/dev/support/forums/
Re: Assembler message (prc-tools)
On 2005-04-21, Miguel Angel Sotomayor Hernandez <[EMAIL PROTECTED]> wrote: > I've searched in the forum archives and I've seen similar problems, but > I haven't been able to solve my problem yet. > > I added a couple of functions to one of my source code file. Because of > the size, my application has 4 segments. After I added these two > functions to "storecheckMain.c" I noticed that one of my sections was > full. So I created a new one and move some functions to this new one. > Then, I tried to compile again but this time there was an assembler > message: > > /home/miguel/tmp/ccIY1ZOg.s: Assembler messages: > /home/miguel/tmp/ccIY1ZOg.s:11841: Error: value out of range > /home/miguel/tmp/ccIY1ZOg.s:11841: Error: Value of -32902 too large for > field of 2 bytes at 0x2b8 > /home/miguel/tmp/ccIY1ZOg.s:11845: Error: value out of range > /home/miguel/tmp/ccIY1ZOg.s:11845: Error: Value of -32912 too large for > field of 2 bytes at 0x2c2 > > and more lines like these. > This could be a very large switch statement. I am suspicious because the linenumbers in the assembly file are large and the 'field of 2 bytes' is probably the switch variable at the beginning of the file. Look at the generated assembly (you can use m68k-palmos-gcc -S) and see for your self what happens at lines 11841 and 11845. If it is a large switch, you will have to break it up in several switch statements for the various ranges of the switch variable. HTH Ton van Overbeek -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Where to find a PalmOS 4.x simulator?
On 2005-04-23, Dr. Vesselin Bontchev <[EMAIL PROTECTED]> wrote: >> You can redirect IRDA to the emulator's serial port or put the >> emulated device in loopback mode. Both are described in the POSE >> manual, IIRC. > > Uhm, *where* is that?? All I could find was some PDF file containing a > document named "Using Palm OS Emulator". It contains the word "infrared" only > once, in the following context: > >> IR port Specifies which port Palm OS Emulator uses to emulate >> infrared communications on the handheld. >> NOTE: This function is not currently supported. > > which pretty much matches my observations. So, how do I do it? I have already > redirected the serial port to TCP/IP and the Net.Lib calls too - but it > doesn't help. > > Regards, > Vesselin Here is something from the old Palm FAQ: -- 3.9 - How can I debug beaming? by Jay Hong To debug beaming, use POSE. Please note that you will need a fairly fast computer for this to be successful (500MHz+). Also note that I have only used this process to beam apps, but it should also allow debugging. 1. Install the program you want to debug on POSE and on a real Palm unit. If there are two different programs, load one onto the Palm and the other into POSE. The one you're interested in debugging goes into the POSE session. 2. Place the Palm in the cradle. 3. Turn off HotSync Manager. 4. Set POSE to use the serial port the cradle is connected to. 5. On POSE, go into MemoPad and enter shortcut.s This redirects IR beaming to the serial port. Do the same on the Palm in the cradle. 6. Beam a database in launcher to ensure that beaming is working correctly. 7. Debug beaming. 8. On Palm, go into MemoPad and enter shortcut.s to direct beaming back to the IR port. Do the same in POSE. If you lose track of whether or not IR is redirected, reset the device. When a device comes out of reset, IR is directed to the IR hardware. --------------A The trick is shortcut s. I have no idea if this also works on PalmOS 5 devices. HTH Ton van Overbeek -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
[ANN] tcpusb-0.1: USB debugging for m68k-palmos-gdb
Finally you can use m68k-palmos-gdb with USB devices. I made a tcp-usb bridge (same idea as Florent Pillet's bridge for MacOS) which works both under Cygwin and Linux. For the impatient: the files are on http://www.v-overbeek.nl/tcpusb . Since I have no way to test all combinations of USB devices and Windows and Linux versions, I need your help to try this out. The best way to send comments is to post them on the PalmSource tools-forum (http://news.palmos.com/read/?forum=tools-forum) and/or sent them to the prc-tools-devel mailinglist at sourceforge ([EMAIL PROTECTED]). When the code turns out to be usable with many devices I might integrate it directly into m68k-palmos-gdb, so you could say something like "target palmos usb:". I have tried tcpusb 0.1 with a Tungsten T and T3 on WinXP/SP2, Win2K, Linux 2.4.27, 2.6.8 and 2.6.11. Also some limited testing with a Handspring Visor was done. One caveat for Linux: The 2.6.11-rcx versions do not work due to a bug in the usbfs code. The major distribution affected by this is Knoppix 3.8.x which uses 2.6.11-rc3. Enjoy. Ton van Overbeek -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: PODS and multi-segment applications
On 2005-05-03, Dr. Vesselin Bontchev <[EMAIL PROTECTED]> wrote: > Hello folks, > > The size of my code 1 segment is approaching 31 Kb, so I guess I should > start hitting various kinds of limits soon... > > First of all, does the gcc compiler have the equivalent of "smart model" > that CodeWarrior has? That is, one that uses short relative jumps, whenever > possible, and long ones to jump accross more than 32 Kb of code? > m68k-palmos-gcc does not support CodeWarrior's smart model. > Second, how do I make my application a multi-segment one with PODS? It ought > to be possible, because it uses the gcc compiler and that compiler (and > linker) supports multi-segment applications, according to this > > http://prc-tools.sourceforge.net/doc/prc-tools_3.html#SEC17 > > but how to do it from PODS? All I could find in the documentation > > http://www.palmos.com/dev/support/docs/dev_suite/PalmOSDevSuite/Tools_Overview.html > > was that > > "Sample code generated by the 68K application wizard contains two files to > help you create multi-segment applications, if your application is > sufficiently large to require multiple segments. These files are Sections.h > and Sections.def. You can read the instructions in these files on how to > use them." > > This isn't terribly helpful. I created a new starter application and at no > point did the wizard ask me whether it is to be a multi-segment > application - and no Sections.* files were generated, either. So, how do I > do it? > Obviously, you use 'managed make' projects in PODS. When you create a 'standard make' project, the Sections.* files are created. To get an idea outside PODS, using only make and gcc, look at the multiapp sample application in prc-tools-samples, available as part of the prc-tools-samples collection in the download section of prc-tools.sourceforge.net. Ton van Overbeek -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Where is the entry point of the applications?
On 2005-05-03, Chris Brooks <[EMAIL PROTECTED]> wrote:
> Yeah, I was right... it's declared like this:-
>
> UInt32 __Startup__ ( void )
> {
> }
>
>
> Dr. Vesselin Bontchev wrote:
>
>>Hello folks,
>>
>>When an executable application is loaded by PalmOS, where is the point that
>>receives control first? No, it is not PilotMain - it's much before that;
>>there is some startup code that calls PilotMain. How to determine the
>>location
>>of the first instruction that will get executed in the code 1 resource?
>>Also, what is the code 0 resource for?
>>
>>Regards,
>>Vesselin
No, only if you are using CodeWarrior.
In m68k-palmos-gcc it is 'UInt32 start(void)'.
The execution starts at the first instruction of the code 1 resource.
The start() function is part of crt0.o. If that file is not linked first,
buildprc or the equivalent in PODS places a 2 word 'jump to start()'
instruction at the beginning of the code 1 resource (which causes all
symbolic addresses to be off by 4 ...).
See the c runtime source in prc-tools CVS on
http://sourceforge.net/projects/prc-tools.
There is some other interesting stuff being done before PilotMain is
called which potential virus writers could use.
The code 0 resource contains preferences about stacksize, etc. Google for
it and you will find some interesting stuff.
The whole resource philosphy was inherited from the classical 68k Macintosh
(including code 0) when PalmOS 1.0 was developed.
Ton van Overbeek
--
For information on using the Palm Developer Forums, or to unsubscribe, please
see http://www.palmos.com/dev/support/forums/
Re: Where is the entry point of the applications?
On 2005-05-03, Dr. Vesselin Bontchev <[EMAIL PROTECTED]> wrote: >> The execution starts at the first instruction of the code 1 >> resource. > > Thanks. Are you sure about this? That was one of the places I thought of > checking and the code there didn't make much sense to me. It looks > something like this: > > ORI.B #1,D0 ; Set the lowest bit of D0 to 1? What for? > PEA $some_small_number > ADDI.L #some_big_number,(SP) > RTS > > Is that a way to transfer control to address = some_big_number + > some_small_number by pushing the result of the addition on the stack and > doing a return? Why does it have to be done in such a bizarre way? Can't > it jump directly? > > Perhaps the reason for my confusion is that my knowledge of the 68k assembly > language is a bit on the lacking side... Maybe it cannot jump directly > because the jmp instruction can take only a relative 16-bit value and the > location could be more than 32 Kb away from the beginning? Then why the > addition? Maybe there isn't an instruction to push a large enough number > on the stack directly? > It has to do with the locking of the code 1 resource into memory. The memory manager can move unlocked resources around to compact the storage heap.i So the launch code looks up the code 1 resource, pushes its start address on the stack and jumps to it with RTS. The D0 register is typically used for integer type return codes by most 68k compilers. >> The code 0 resource contains preferences about stacksize, etc. >> Google for it and you will find some interesting stuff. > > Oh, I did - but the article I found told me that "it is not clear what the > code 0 is for" and that different compilers seem to put different things > there. :-) > > Also, I thought that things like the stack size, etc. were put in an > application preferences resource? At least the resource editor of PODS > offered me to put such things there when I tried creating such a resource > - originally I thought that I could put some preferences specific to my > application in such a resource; you know, the kind of stuff that > PrefSetAppPreferences saves. > All old PalmOS history ... Now, indeed the requested (68k) stack size is part of the preference resource. Look at the SystemMgr.c code in the Limited PalmOS 4 sources. You'll find the answer to your questions there. Ton van Overbeek -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Where is the entry point of the applications?
On 2005-05-03, Ben Combee <[EMAIL PROTECTED]> wrote: > At 11:03 AM 5/3/2005, you wrote: >> > It has to do with the locking of the code 1 resource into memory. >> > The memory manager can move unlocked resources around to compact >> > the storage heap.i So the launch code looks up the code 1 >> > resource, pushes its start address on the stack and jumps to it >> > with RTS. >> >>Sorry, I still don't understand. Most of what you describe above is done >>by the OS (the Memory Manager). OK, so it finds the most appropriate place >>where to move the code 1 resource, locks it, and transfers control to it. >> >>But it's not it (the Memory Manager) that does the weird push/ret stuff - >>it's the first few instructions of the loaded code 1 resource. Are you >>saying that, after loading them in memory, the memory manager *modifies* >>the operands of these instructions, in order to reflect the place of the >>code 1 resource in memory? > > No... look at the code at the start of a CW 'code' #1 segment again: > > ORI.B #$01,D0 ; '.' | 0001 > 0004PEA *+$0006 ; 000A| 487A 0004 > 0008ADDI.L#$0FB6,(A7) ; '' | 0697 0FB6 > 000ERTS | 4E75 > > The instruction at is filler -- I think it's there because of some > quirk on the old Macintosh. > At 0004, you push the current address plus 6 on the stack. This gets > you a pointer into the currently executing code. > At 0008, you modify that address by adding a value to it. This is the > offset into the 'code' #1 resource where __Startup__ lives, and is set at > link time. > At 000E, you jump to that address using an RTS instruction. > > Is this the simplest code that can do this? Yes, at least using the > original 68K instruction set. If you look at long jumps in the CW > generated code after a link, you'll see a similar sequence. If the linker > put __Startup__ at the beginning of the resource, then this wouldn't be > needed, although CW's linker doesn't do that optimization. If __Startup__ > was within 32K, it could be done with a direct jump, but its easier in the > linker to always assume a long jump here, as that avoided multiple code > paths and kept the offset to the first real code the same. > Sine I am a prc-tools guy, I did not know the CodeWarrior startup, and hence the code sequence Ben commented above. Prc-tools uses a much simpler approach: the linker is called with crt0.o as first object file. Hence start() is at offset 0 from the .text section in the linker output. Normally the .text section maps one to one to the code 1 resource. If startup() (for some reason, i.e. SysLibs) is not at the beginning of the .text section, then buildprc puts in a jump to start() at the beginning of the code 1 resource. By the way, this possible moving around of code resources in the Palm memory is the reason the code is normally compiled as PIC (Position Independent Code). Hence the limitation of +/-32K branches. Otherwise you need extensive relocation in the runtime startup. Ton van Overbeek -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: shut down problem
On 2005-05-04, Scott Erickson <[EMAIL PROTECTED]> wrote:
> Henk,
> Could this be the reason... I have a struct to hold my app settings. I
> make one declaration of that to be global. In appstart i allocate memory
> for it with memptrnew and a temporary memprt. then i use in in many
> functions with no problems. then in appstop i try to free the memory with
> MemPtrFree(currentSettings); yet the simulator tells me i have an unfreed
> chunk (same as the value of the pointer to the variable), and the device
> softresets at this point. how can i free the chunk of mem i am using for
> this variable? below is some relavent code from my app...
>
> (the declaration is above all function calls, but below all function
> headers)
> typedef struct{
> Boolean monitor;
> UInt32 aUpdate;
> Char* lastUpdate;
> Char* license;
> } appSettings;
> appSettings *currentSettings;
>
> (in appstart)
> MemPtr temp;
> UInt16 appSettingsSize;
> appSettingsSize = sizeof(currentSettings);
^^^
This is wrong. sizeof(currentSettings) is 4 since currentSettings is a
pointer. I guess you mean sizeof(appSettings) instead.
Hence your allocated memory is too small and you are overwriting other
memory.
> temp = MemPtrNew(appSettingsSize);
> currentSettings = temp;
>
> (in appstop)
> MemPtrFree(currentSettings);
>
Ton van Overbeek
--
For information on using the Palm Developer Forums, or to unsubscribe, please
see http://www.palmos.com/dev/support/forums/
Re: debug treo - is it possible?
On 2005-05-05, IanB <[EMAIL PROTECTED]> wrote: > libusb-win32 filter locks my machine up and won't uninstall. I can't > reinstall, either. Help. > Under W2k/XP it starts a process called libusbd-nt.exe. Start Windows Task Manager, find it under Processes, and kill it before you try to uninstall it. Maybe this helps. I have no experience with libusb under W98/Me. Ton van Overbeek -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: debug treo - is it possible?
On 2005-05-06, IanB <[EMAIL PROTECTED]> wrote: > Should I use the standard cygwin or the palmos cygwin? I've installed the > standard cygwin, is that a problem? Using the standard Cygwin installation is fine. This is what I am doing myself. I keep my Cygwin installation up to date and my PODS uses the standard Cygwin installation (custom installation of PODS). Using different versions of Cygwin on the same computer is asking for trouble. In an email to me you asked what to do with tcpusb-0.1.tar.bz2. Open a Cygwin command window and go to the directory where tcpusb-0.1.tar.bz2 is located. Unpack the archive with the command 'tar jxvf tcpusb-0.1.tar.bz2'. The contents of tcpusb-0.1.tarbz2 is: tcpusb-0.1/Cygwin/tcpusb.exe tcpusb-0.1/Linux-x86/tcpusb tcpusb-0.1/README tcpusb-0.1/src/logtraffic.c tcpusb-0.1/src/slk.c tcpusb-0.1/src/tcpside.c tcpusb-0.1/src/tcpusb.c tcpusb-0.1/src/usbside.c The Cygwin executable is (guess): tcpusb-0.1/Cygwin/tcpusb.exe. Ben Combee wrote: > Yes, you need the driver that's installed with the Palm Desktop 4.1 that > comes with the Treo 600. Just to be clear: You need this driver for HotSync. For debugging it is not needed. HTH Ton van Overbeek -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: debug treo - is it possible?
On 2005-05-06, IanB <[EMAIL PROTECTED]> wrote: > Not sure if I replied group. > > (Also, what is the unix command to change directory?) > > I use CW9, not the PODS. m68k-palmos-gdb uses output only from PODS, and not > CW9? The fileformat from CW9 is *not* compatible with prc-tools. You do not need the full PODS to recompile your app with prc-tools, you can also use classical command-line tools and make (which is what PODS does behind the scenes anyway). > Is there a process to switch from one IDE to the other, so I can easily > produce the file required for m68k? I'll research the PODS documentation, > but I am under the impression projects are developed in one IDE or the > other. > Main problem is the conversion of resources (form, bitmaps etc.) and the different way multiple sections/segments are handled. For a single section/segment application it could be fairly easy. Ton van Overbeek -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Which pipe to use when connecting to palm via USB cradle
On 2005-05-09, Rob <[EMAIL PROTECTED]> wrote:
> Hi
>
> I have already got all the code I need to connect to my palm using the USB
> cradle.
> I am currently opening the pipe using:-
>
> CreateFile("\\?\vid ... \\PIPE00", etc...)
>
> Whilst this works fine for my Tungsten T3, my Tungsten T uses different
> pipes for the network connection.
>
> T3 uses pipe00(read) and pipe01(write)
> T uses pipe02(read) and pipe03(write)
> Tests have shown other devices use various combinations of pipes
>
> My code must support various devices so I need a way of determining which
> pipes are used by the device.
>
> I have tried opening all the pipes and simply using the first one that sends
> data but this can cause a bluescreen if the palm is doing a cradle
> hotsync.
>
> How can I determine the correct pipe to use for any device?
Look at how it is done in libpisock in pilot-link:
http://cvs.pilot-link.org .
For PalmOne devices use PALM_GET_EXTENDED_CONNECTION_INFO and look for the
pipes with the function_id 'psys'. These are the console/debug ports on
USB devices. For other devices you have to do other things.
See also the darwinusb.c file in libpisock.
HTH
Ton van Overbeek
--
For information on using the Palm Developer Forums, or to unsubscribe, please
see http://www.palmos.com/dev/support/forums/
Re: Help me,It's Urgent..Debugging Problem
On 2005-05-09, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Hello, > >I am using CYGwin PRCTools on windows. I want to debug it on TREO600 > Simulator.Previouly,Project was on Linux Environmnt. To debug for > TREO600(able for windows only),I had to shift it to windows. I am able to > connect on POSE(Emulator)but not to TREO600 Simulator. > > Please help me out. Thank You. > One big difference between POSE and the various simulators is that you have to use the 'gdbpanel' application on the simulators in order to set the 'gdbS' feature needed for debugging with m68k-palmos-gdb. See Section 5 (http://prc-tools.sourceforge.net/doc/prc-tools_5.html) in the prc-tools documentation for more details. Also if you do see the 'waiting' message in m68k-palmos-gdb it means the TCP connection to the simulator port 2000 has been established. HTH Ton van Overbeek -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Help me,It's Urgent..Debugging Problem
On 2005-05-10, Dr. Vesselin Bontchev <[EMAIL PROTECTED]> wrote: >> One big difference between POSE and the various simulators is that >> you have to use the 'gdbpanel' application on the simulators in >> order to set the 'gdbS' feature needed for debugging with >> m68k-palmos-gdb. > > You don't need anything like that when using the default PODS debugger (i.e., > when you click on the green bug button) - I assume it means that it is > using a different debugger. What you're saying probably holds for the > stand-alone debugger - the one that is accessed by clicking on the red > bug button of PODS. No, the stand-alone debugger in PODS does not need gdbpanel. It uses a different way to get the necessary information (mainly the start addresses of the various segments). gdbpanel is only needed if you are using the m68k-palmos-gdb debugger included in prc-tools. > > Speaking of gdbpanel, is the PRC file available from somewhere? I found the > source easily enough but it's a PilRC project and I'm using PODS and > don't feel like converting it into a PODS project just in order to compile > it... > Where did you get the source ? Both download versions on the sourcefore download page (http://sourceforge.net/project/showfiles.php?group_id=4429) prc-tools-samples.tar.gz and prc-tools-samples.zip contain the final prc files. No need to compile yourself. Ton van Overbeek -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Unusual problem.
On 2005-05-28, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Hello,
> I am facing a very usual problem. My application run fine on zire and
> tungsten series, but on Treo600 it crashes.
> Output of debug is as follows. The HashedStringCompare Function doesn't
> return to position from where it is called. instead it again start
> execution from the 153 lines. Please help me out
>
> m68k-palmos-gdb -command=debugfile Fortress
> GNU gdb 5.3-tvo-20031229
> Copyright 2002 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 "--host=i686-pc-linux-gnu --target=m68k-palmos"...
> debugfile:1: Error in sourced command file:
> localhost:2000: Connection refused.
> (gdb) target palmos
> Remote debugging under PalmOS using localhost:2000
> Waiting... (Press Ctrl-C to connect to halted machine)
>
> Program received signal SIGSTOP, Stopped (signal).
> PilotMain (cmd=0, cmdPBP=0x0, launchFlags=174) at Fortress.c:7362
> 7362 UInt32 alarmTime = 0,nowTime = 0;
> (gdb) b 8539
> No line 8539 in file "Fortress.c".
> (gdb) b 5839
> Breakpoint 1 at 0x11106794: file Fortress.c, line 5839.
> (gdb) c
> Continuing.
>
> Breakpoint 1, SetPassword3FormHandleEvent (eventP=0x102d69c4) at
> Fortress.c:5839
> 5839
> GetFieldText(SetPassword3FormField,&passwordString);
> (gdb) n
> 5840 StrCopy(digest,passwordString);
> (gdb) n
> 5841 result = HashedStringCompare(gMasterPassword,
> digest);
> (gdb) s
> HashedStringCompare (
> hashedString=0x10027684 "?o8\nÈÎ|[EMAIL PROTECTED]",
> newString=0x102d4910 "a") at crypto.c:149
> 149 MemSet(digest, kMD5HashSize, 0);
> (gdb) n
> 150 StrCopy(digest, newString);
> (gdb) n
> 151 GetMD5HashedString( digest );
> (gdb) n
> 153 result = StrCompare(hashedString, digest);
> (gdb) n
> 154 StrCopy(newString, digest);
> (gdb) n
> 157 return true;
> (gdb) n
> 0x1110736e 160 }
> (gdb) n
> 153 result = StrCompare(hashedString, digest);
> (gdb) n
> 154 StrCopy(newString, digest);
> (gdb) n
>
>
>
> Heres is the Function
> Boolean HashedStringCompare( CharPtr hashedString, CharPtr newString){
> Int8 result = 0;
> Char digest[kMD5HashSize];
> MemSet(digest, kMD5HashSize, 0);
> StrCopy(digest, newString);
> GetMD5HashedString( digest );
> //if(digest != 0 && hashedString != 0)
> result = StrCompare(hashedString, digest);
> StrCopy(newString, digest);
>
> //if(result == 0)
> return true;
> //else
> //return false;
> }
>
> Regards
> Deepak Singh
Your digest string is a local variable and hence on the stack. Check if
the StrCopy calls do not overwrite the allocated storage for digest.
If they do, they might overwrite the return address (also on the stack)
and hence the function returns to some arbitrary location.
Maybe you were just lucky on Zire and Tungsten.
Inspect your strings and use assembly level debugging to inspect memory.
HTH
Ton van Overbeek
--
For information on using the PalmSource Developer Forums, or to unsubscribe,
please see http://www.palmos.com/dev/support/forums/
Tcpusb-0.2 available. Fixes debugging on Treo 600.
This version fixes the debugging for the Treo 600. This did not work in tcpusb-0.1. Thanks to Deepak Singh for reporting the problem and testing the new version and to Florent Pillet for assisting in finding the solution. Tcpusb-0.2 can be found at http://www.v-overbeek.nl/tcpusb . Please report successes and failures on the PalmSource tools forum or on the prc-tools-devel mailinglist. Enjoy. Ton van Overbeek -- For information on using the PalmSource Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Debugging with PODS on Tungsten T
On 2005-06-01, Jonathan Dudley <[EMAIL PROTECTED]> wrote: > Hi again, > > Sorry, I have searched for an answer to this question, but was unable to > find it. Any help? > > Thanks again. > > "Jonathan Dudley" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] >> Hi All, >> >> Sorry, I have looked in the archives for an answer to my question, and was >> unable to figure out my problem. >> >> I have a Palm Tungsten T, and have recently downloaded PODS (Version: >> 1.2.0.23, Build ID: 19E_120GMC). Debugging on the Emulator and Simulator >> seems to be working, but I am unable to debug on my Tungsten T. My >> Tungsten >> T is connected to my PC via the USB cradle. I have placed it in console >> mode >> using the dotdottwo program. >> >> I have created the hello world application sample project for a managed >> make >> 68k project, and when I try to debug using Device (USB) as the target I >> get >> the following error: >> >> Launching (Error: Target request failed: Target is not responding (timed >> out).) >> >> There are more details in the details window, but as I seem to not be able >> to copy from the window, I would have to type it out. If you need these >> details to solve the problem I can do so. >> >> My question is, should I be able to debug on the device, or is there some >> issue with the Tungsten T? Please help! >> >> Thanking you all in advance, >> >> Best regards, >> >> Jonathan Have you stopped/disabled HotSync? A running HotSync will 'grab' the USB connection. HTH Ton van Overbeek -- For information on using the PalmSource Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: PODS 1.2 - Still not running correctly
On 2005-06-03, Jürgen Wind <[EMAIL PROTECTED]> wrote: > Hi folks, > > I know that you can't hear it anymore, but the problem still persists: > > PODS 1.2 doesn't start program in Simulator or Emulator ( same problem > as with PODS 1.1 ) > PODS 1.0 runs fine. > > The error is: > > Unable to launch Target Environment: > org.eclipse.cdt.debug.mi.core.MIException: > org.eclipse.cdt.debug.mi.core.command.Command.throwMIException(Unknown > Source) > org.eclipse.cdt.debug.mi.core.command.Command.getMIInfo(Unknown Source) > com.palmsource.eclipse.palmoscore.internal.launch.PalmLaunchDelegate.postCommand(Unknown > Source) > com.palmsource.eclipse.palmoscore.internal.launch.PalmLaunchDelegate.launchForRunning(Unknown > Source) > com.palmsource.eclipse.palmoscore.internal.launch.PalmLaunchDelegate.launch(Unknown > Source) > org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:569) > org.eclipse.debug.internal.ui.DebugUIPlugin.buildAndLaunch(DebugUIPlugin.java:788) > org.eclipse.debug.internal.ui.DebugUIPlugin$6.run(DebugUIPlugin.java:955) > org.eclipse.core.internal.jobs.Worker.run(Worker.java:66) > > org.eclipse.cdt.debug.mi.core.MIException: > org.eclipse.cdt.debug.mi.core.command.Command.throwMIException(Unknown > Source) > org.eclipse.cdt.debug.mi.core.command.Command.getMIInfo(Unknown Source) > com.palmsource.eclipse.palmoscore.internal.launch.PalmLaunchDelegate.postCommand(Unknown > Source) > com.palmsource.eclipse.palmoscore.internal.launch.PalmLaunchDelegate.launchForRunning(Unknown > Source) > com.palmsource.eclipse.palmoscore.internal.launch.PalmLaunchDelegate.launch(Unknown > Source) > org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:569) > org.eclipse.debug.internal.ui.DebugUIPlugin.buildAndLaunch(DebugUIPlugin.java:788) > org.eclipse.debug.internal.ui.DebugUIPlugin$6.run(DebugUIPlugin.java:955) > org.eclipse.core.internal.jobs.Worker.run(Worker.java:66) > > > I know that I'm not the only one. > > All the people have more or less the same configuration: > > Windows XP SP2 Home/Professional GERMAN, Firewall off > > It's seems to be a strange coincidence, but all the Windows versions are > German ones. > > I doubt that this is a conspiracy started at PalmSource ;-) > > I would really, REALLY love to use the new features of PODS 1.2 and > don't want to be stuck with 1.0 > > So, dear people at PalmSource, what can we do to help you resolve the > problem ? > The reason/solution to this was give a few days ago. Eclipse uses netstat to check if something is listening on port 2000. It uses 'netstat -aop' and searches for the string LISTENING. In a German Windows versions 'netstat -aop' returns strings not with LISTENING but something with HÖREN. Quick and dirty solution: replace netstat with the one from an English Windows version. HTH Ton van Overbeek -- For information on using the PalmSource Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Putting globals in code sections, side effects ??
On 2005-06-09, Nicolas T. <[EMAIL PROTECTED]> wrote: > Hello > > I am using prc-tools 2.3 on Cygwin 1.5.10 and Windows XP SP2. > > From what I understand, the "section" attribute affects only code. > Until now I thought specifying a section for global variables > had absolutely no effect. > > However, I am working on a project where it has been done, and > we are seeing unexpected results like the program crashes or > variables that get overwritten. > > The code generated is not quite the same then. > It seems putting a variable "in" a section (whatever that means > for a variable) does have some effect after all (although > said effect is undesirable). > > Can someone comment on this? > Which is correct: > Specifying a section for a global variable > - should NOT be done? > - has no effect? > - should be done under certain circumstances? > - other? > > Thanks, > Nicolas All global variables end up in the single data.0 resource in the prc. There is no such thing as multiple data sections. >From this it is quite obvious: - Do *not* specify a section for a global variable. If you do, there is a chance of overlapping variable references (as you noticed). HTH Ton van Overbeek P.S. Is this the same problem you addressed in tools-forum? -- For information on using the PalmSource Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Putting globals in code sections, side effects ??
On 2005-06-10, nthamer n <[EMAIL PROTECTED]> wrote: > Ton, > > Thanks for your reply > >> - Do *not* specify a section for a global variable. >> If you do, there is a chance of overlapping variable >> references (as you noticed). > > So if I did > - var1 in default section > - var2 in section 1 > > The compiler would generate code to access: > - var1 at offset 0 in default section > - var2 at offset 0 in in section1 > > But the the linker creates one section for all data > So var1 and var2 overlap > > Correct? > Yes, it is a bit more complicated than this, but the references to the global variables generated in the code have this efect. -- For information on using the PalmSource Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: the LifeDrive simulator
On 2005-06-11, Paul Nevai <[EMAIL PROTECTED]> wrote: > Dear All: > > Has any of you managed to use the standard "Address Lookup" menu command [aka > PhoneNumberLookup()] found in most PIM apps on the LifeDrive simulator? Mine > crashes immediately. > > Could you please test this on your simulator, say, on Memos? > > /PaulN > Works for me. Run LifeDrive sim after extracting from zip. Select Memos Select Memo 1 Power Tips Menu->Options->Phone Lookup Lookup window with 2 Contacts (Accessories and Techniccal Support) This is on Win XP/SP2 Ton van Overbeek -- For information on using the PalmSource Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Problems with the Debugger
On 2005-06-16, Edgar T. López <[EMAIL PROTECTED]> wrote: > I did not put the error messages that the Palm OS Debugger show me. > > "Failed to connect to target using the 68k Palm OS Debug kernel Protocol > Plug-in Protocol" > > "Check protocol and communications preferences, cables and target hardware > and try again". > > Thanks. > > Edgar T. López Are you using a non-English (e.g. Spanish) Windows version ? Then this problem (non English netstat not producing the string LISTENING) was discussed last week. See e.g. the posts by Benjamin Stadin: http://news.palmos.com/read/messages?id=191307 Ton van Overbeek -- For information on using the PalmSource Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: PODS 1.2.1.02 and Resource Editor 6.3.0.1
On 2005-06-18, Robert Rhode <[EMAIL PROTECTED]> wrote: > Hi everyone, > > We at PalmSource have been following the recent discussions regarding > the PODS 1.2.1.02 update. We're aware of a couple of significant bugs, > and want to communicate to you our position on it before the flames get > too hot. > > We regret that the update got out the door with any bugs. However, as > has been previously noted in the Forum, the 1.2.1.02 update is a > technology preview, and in order to install it you have to agree to a > "prototype license agreement" that explains the prerelease nature of the > software and asks you in good faith to test it and report bugs back to > PalmSource. This is the only way we can give you early access to > improvements in advance of major releases. In light of this, I think > it's a bit unfair to blame us for the unfinished quality of the preview. > Just a few remarks. In the Eclipse Manage Configuration dialogs this update never showed up in the Technical Preview category, but as a normal available update. The info text only said "This replaces the complete PODS feature" or something similar. I believe you need to change your packaging process, so the nature of the update (preview, which features/plug-ins have changed, etc.) are directly presented in the eclipse update dialogs. Now it was far too obscure and hence the confusion. I personally never saw the "prototype license agreement" but assumed it was the normal PODS license agreement. I could revert back to the previous resource editor, but lost my Cygwin environment variables and mount points in the process (have an own Cygwin installation and used Custom install). But I know you are already aware of these Cygwin issues. > The product managers for Palm OS Developer Suite met to discuss the > resource header bugs in PODS 1.2.1.02. There was a general sentiment > that we should recall the update, but I argued in favor of keeping it. > In addition to various bug fixes, I feel that Constructor-style > automatic header generation is a sufficiently worthwhile feature that it > should be available even in its semi-broken state. I've been clamoring > for this since last fall, and I'm not about to give it up now that it's > here. > > It's easy to roll back to an older configuration of PODS if you don't > like the update. Here's a KB article that describes how to do it: > > http://kb.palmsource.com/cgi-bin/palmsource.cfg/php/enduser/std_adp.php? > p_faqid=1047 > > For those of us who prefer Constructor-style headers, here's a KB > article describing how to live with the bugs in the current technology > preview: > > http://kb.palmsource.com/cgi-bin/palmsource.cfg/php/enduser/std_adp.php? > p_faqid=1048 > > I hope this adequately addresses the issues with the current PODS > update. > > We're always interested in your constructive feedback and > recommendations on how to improve our products. Thank you for your bug > reports and suggestions; keep them coming! > > Best regards, > > - Sparky > > -- For information on using the PalmSource Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Getting Hotsync back after PODS debug on device
On 2005-06-21, Matthew D Moss <[EMAIL PROTECTED]> wrote: > I recently installed PODS and built a simple "hello world" app to test > tools, connection, etc. After a few minor glitches I was able to debug on > the device through the Eclipse debug perspective. > > Now, my Palm is sluggish at times (usually power on/off) and cannot hotsync > over usb(because the "port is in use"). I take it this is because PODS must > have installed a "debug nub" (or something?) to make debugging as easy as it > was. > > I'm glad that I can debug so easily on device; but is there as easy a way to > temporarily disable the nub so I can hotsync over usb? You will have to get the device to close the debug port (that is why you get USB port in use). The only way (I know) to do this is by soft-resetting the device. Also when the debug port is conyinuously open, you will drain the battery faster. The sluggishness is caused by the console handler code executing, listening for a command all the time in the background. So, soft-reset and the slugghishness should disappear and you should be able to HotSync again via USB. HTH Ton van Overbeek -- For information on using the PalmSource Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: PODS code sectioning question
On 2005-07-07, Bryce Burrows <[EMAIL PROTECTED]> wrote: > Hi everyone > i have a problem with the section of my code. > I have been working on an application in PODS which is going well. > I have a number of sections (6) all which contain code and it builds just > fine. > > However when I added a function to one of my code sections (a simple string > replace function of about 25 lines) the build failed with the following error > >= > /usr/m68k-palmos/bin/ld: region coderes is full (Expert section .text) > /usr/m68k-palmos/lib/libcrt.a(multi_dreloc.o)(.text+0xe): In function > `_GccLoadCodeAndRelocateData': > dreloc.c:56: relocation truncated to fit: DISP16 start > collect2: ld returned 1 exit status >== > > > Which indicates to me that the section is full - so i add an extra code > section, and assign the function to that code section > and attempt a clean then rebuild...and it fails again (noet the function is > actually being called anywhere yet) > > have i missed something? I understand that the code should be going into the > newly defined code section and thus shouldnt cause any problems. > > Does anyone have any suggestions? > Your new code may pull in some extra c library routines. These will be placed in the main code section (.text which becomes code resource 1). I guess that is what is pushing you over the .text edge ;-). The work around is to move some more routines to the extra code sections. Producing a linker map might help to pinpoint the problem. See gcc/ld docs for details on how to produce a linker map. Ton van Overbeek -- For information on using the PalmSource Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: build-prc problem using prc-tools
On 2005-07-14, Gnadinger, David <[EMAIL PROTECTED]> wrote:
>
> Here is my entire makefile. I'm pulling my hair out trying to figure out
> what is wrong. I may have another problem other than the one stated.
>
> Thanks to anyone who can help (and save the rest of my hair!).
>
> Dave
You never pass the output of the linking phase (src/${APPNAME}) to
build-prc. Do *not* pass the individual compiled object files to
build-prc. Of course you *do* need to pass the resources (*.bin).
So modify your make rule according to this and it should work.
HTH
Ton van Overbeek
--
For information on using the PalmSource Developer Forums, or to unsubscribe,
please see http://www.palmos.com/dev/support/forums/
Re: HostVFPrintF is missing from header files?
On 2005-07-14, Paul Reger <[EMAIL PROTECTED]> wrote: > I see a declaration for: > > long HostVFPrintF ( >HostFILEType *f, >const char *fmt, >va_list args) > > at http://www.palmos.com/dev/support/docs/protein_books/System_Management/ > HostControl.html#1007298 > > But there does not seem to be one in: > > c:/program Files/Metrowerks/CodeWarrior/Palm OS Support/Incs/Core/System/ > HostControl.h > HostVFPrintF only exists in sdk-6 for Protein (PalmOS 6) apps. For Garnet (PalmOS 5.x and before) you will have to use a combination of HostFPrintF and StrVPrintF (defined in StringMgr.h>). See http://www.palmos.com/dev/support/docs/palmos/PalmOSReference/StringManager.html#1065754 HTH Ton van Overbeek -- For information on using the PalmSource Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: build-prc problem using prc-tools
On 2005-07-14, Gnadinger, David <[EMAIL PROTECTED]> wrote:
> Apparently I still have a problem with my makefile. The code compiles great
> now, but when I make changes to the ${APPNAME}.c file, the changes never
> show up in the executable (${APPNAME}.prc). I block out complete sections of
> code and it's like I haven't blocked out anything at all. Here's my
> makefile as it looks now:
>
>
> ${DIR}/${APPNAME}.prc : obj/${APPNAME}.o \
> obj/${APPNAME}-sections.s obj/${APPNAME}-sections.ld \
> obj/${APPNAME}-sections.o obj/tFRM03e8.bin \
> themes/*.bin src/${APPNAME}
> @echo "Building final prc..." && \
> build-prc -o $@ obj/${APPNAME}.def src/${APPNAME} -n "${APPNAME}" -c
> gna7 =
> obj/*.bin themes/*.bin
>
When you rebuild your app after editing srs.c (${APPNAME}.c) do you see
all steps (compile, link, build) being executed ?
In the dependencies of ${DIR}/${APPNAME}.prc you can remove
obj/${APPNAME}.o and all the *sections* files.
Of course you will have to reload the prc into the
emulator/simulator/device after the rebuild.
Ton van Overbeek
--
For information on using the PalmSource Developer Forums, or to unsubscribe,
please see http://www.palmos.com/dev/support/forums/
Re: build-prc problem using prc-tools
On 2005-07-18, Gnadinger, David <[EMAIL PROTECTED]> wrote:
> I took the ${APPNAME}.o dependency out but I still have my problem. The code
> still runs the function that I commented out - as if it's still there. It's
> not getting compiled in somehow.
Please provide some more details about whereand how you run the code after
recompiling and building the prc. Are you running the code on the emulator,
simulator on a real device, inside/outside of PODS.
Are you reloading the prc on the sim/emulator/device ?
After your previous posts, it seems the app recompiles, links and build
correctly. So the only remaining place is this 'reloading the app' phase.
If everything else fails, use a debugger.
Ton van Overbeek
--
For information on using the PalmSource Developer Forums, or to unsubscribe,
please see http://www.palmos.com/dev/support/forums/
Re: SysSetOrientation user cache
On 2005-08-01, Tam Hanna <[EMAIL PROTECTED]> wrote: > Hi, > I am currently testing a program that sets the screen orientation using > SysSetOrientation when an appLaunch notification is received. > Now, some apps jump back into another mode after their first form pops up. > I am pretty sure this call is the troublemaker: > PINSetInputAreaState(pinInputAreaUser); > There must be some kind of internal cache in the PIN manager like the sound > manager has. For example, this calls dont work(Tungsten T3 does not stay > in orientation 3): > SysSetOrientation(3); > SysSetOrientation(0); > But which call should I use to update it? > Best regards and thanks > Tam Hanna > > Created on the go using Versamail 2.6.1 on a Tungsten T3. Please accept my > apologies for formatting! I am not sure I uderstand your scenario here. But I have seen similar behaviour in apps which use the DIA routines incorrectly. E.g. if the main form sets the DIA policy, but a modal form (e.g. the about) form does not you can get the following scenario: Start app in portrait. Call About form. Return to main form. Change orientation to Landscape. Call About form again. Now the orientation will change back to protrait automatically. Solution: Call PINSetInputAreaState(pinInputAreaUser) for the modal form. I am writing this from memory, so I cannot guarantee 100% correctness, but I hope it helps. Ton van Overbeek -- For information on using the PalmSource Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Serial on Palm IIIxe
On 2005-08-12, John Powers <[EMAIL PROTECTED]> wrote: > One of my users has purchased a refurbished Palm IIIxe from Fry's > Electronics (for $29.95!). It has Palm OS v4.1 installed. My software > uses the RS-232 serial port and when the serial port is opened, he gets > the error message "unsupported processor type". > > Does this mean the IIIxe does not support RS-232? > Does any Palm III support RS-232? > The IIIxe (and all older Palms) Hotsync via RS-232. So serial is supported. Something else must be going on here. Ton van Overbeek -- For information on using the PalmSource Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Creating Apps that runs on 320x480 screens
On 2005-08-24, Régis Daniel de Oliveira <[EMAIL PROTECTED]> wrote: > Hi forum! > > Actually I develop apps to PalmOS plataform using CodeWarrion 9.3. I always > developed applications that runs on standart screens (160x160, 320x320), > and now, i want do develop an app that will work on palms that have > 320x480 screens. > > When my actual apps runs on devices that have 320x480 screens, its continues > runing as 320x320. > > So, what i need to now is how do develop an app that runs both on 320x320 > and on 320x480 since, when running on 320x480, the forms should occupy > all the screen. > > Could anybody give me some examples/documentation of how could i do this? > > Ps.: I'd like to continue using CW. I still did't had time to learn PODS. > > Thanks!!! > Read up on the programming of the DIA (Dynamic Input Manager) and the PIN (Pen Input) manager in the Garnet Documentation. Also in the PalmSource knowledgebase there is sample code (SampleCollapse) which shows you how to use these calls. The SampleCollapse code is not usable in open source applications due to license restrictions. There is an open source project at sourceforge (http://sourceforge.net/projects/palmresize) which has code which can be used (and is used) in open source projects. HTH Ton van Overbeek -- For information on using the PalmSource Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: where to download the tungsten E debug nub?
On 2005-08-29, meffee <[EMAIL PROTECTED]> wrote: > i want to debug a program on tungsten E device, > the instruction in debugger guilde > give the link below: > http://pluggedin.palmone.com/ > but i didn't find the debugnub prc file > there:( could somebody help the location? > thanks! > >From the ARM Debug Nubs page on pluggedin.palmone.com: ARM debug nubs enable on-device debugging and allow debuggers to break and step through ARM codes. Available are the debug nubs for: Tungsten T, Tungsten T2, Tungsten T3, Tungsten C and Zire 71. All newer devices have built-in debug nub. ^ Since the Tungsten-E is newer than the devices mentioned above, I am pretty sure the E has a built-in ARM debug nub. I do not have an T-E myself, so I cannot check it. All PalmOS5 devices support 68K debugging out of the box. HTH Ton van Overbeek -- For information on using the PalmSource Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: PalmOne SDK 3.0
On 2005-08-29, Scott Erickson <[EMAIL PROTECTED]> wrote: > Im looking for a version 3.0 of the SDK. I need it for the VPN Shim API, > does anyone have a link to where I can download this version of the API? > Go to the downloads section on pluggedin.palmone.com (On the left hand side select develop->downloads). You'll find it there. Ton van Overbeek -- For information on using the PalmSource Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: 5-Way Navigator handling
On 2005-08-31, Ben Combee <[EMAIL PROTECTED]> wrote: > At 05:26 PM 8/31/2005, Jim McGowen wrote: >>Used to be I could just use the macros defined in PalmNavigator.h(now >>PalmOneNavigator.h), simple as pie, but eveidently they don't work for newer >>devices like the T5 (by the way this is not decumented anyplace I could >>find). > > The current palmOne SDK 5.0 download has macros that handle both the older > Palm-specific scheme introduced on the Tungsten T, and the newer PalmSource > 5-way system that is used on the Treo 600/650/T5/everything new. The > IsFiveWayNavEvent(eventP), NavSelectPressed(eventP), and > NavDirectionHSPressed(eventP, nav) macros handle both key schemes. > > -- Ben Combee, Senior Software Engineer, Palm, Inc. > "Combee on Palm OS" weblog: http://palmos.combee.net/ > Developer Forum Archives: http://news.palmos.com/read/all_forums/ I have been fighting/struggling with the 5way navigator in the various simulators in the last few days. The macros in the palmOne SDK 5.0 work for everything up to the T5. However they do not work correctly for the LifeDrive and TungstenE2 debug simulators. When select is pressed the T5 sim sends the sequence (with aprropriate modifiers) vchrHardRockerCenter (press), vchrHardRockerCenter (release), vchrRockerCenter. However the LifeDrive and E2 sims do *not* send the final vchrRockerCenter. I do not know what the real devices do. Also the NavDirectionPressed macro returns true for both key press *and* key release for the left and right keys on the LifeDrive and E2 simulators. Is this a simulator issue or a real change in the later 5.4.x Garnet versions? Any more specific information on these later devices? On all these simulators (T5, Lifedrive, E2) I am using Alt-arrow and Alt-Enter for the 5way keys. Ton van Overbeek -- For information on using the PalmSource Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: How to find a bug that crashes Simulator?
On 2005-09-02, Luc Le Blanc <[EMAIL PROTECTED]> wrote: > I encounter an odd crash running my own app on my T3. The problem does > not show on other devices, nor POSE, only on an actual T3 and the T3 > Simulator (I haven't checked all Simulator flavors). When I hit a given > line that calls FrmShowObject on a previously shown gadget, the > Simulator plainly crashes (I naively thought it was designed to help > find bugs, not to go down with them ;) I suspect some form of memory > corruption occurring prior to the crash. Are there strategies to debug > such problems? Is all I need for on-device debugging with CW 9.3 is a > serial cable hooked to the T3? > > As a side effect, I note that sometimes, after this crash, my hardware > buttons get reassigned to different applications (all 4 were linked to > Planetarium last time) even if everything remains unchanged in the > Buttons tab of the Prefs program. This and the crash also appeared on > another T3. > You have already solved the problem causing the crash, but here my 5 cents worth. The T3 simulator is a release version. There is no debug version of the T3 sim. Try using the debug version of the T5 simulator. In my experience it ususally throws up a few alerts informing you about things it does not like (like forms not being full widht, etc.) before it comes to the point where it actually crashes. Maybe something for your next problem ... Ton van Overbeek -- For information on using the PalmSource Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Vector To Error Info?
On 2005-09-06, Lance Drake <[EMAIL PROTECTED]> wrote: > Hi Palm Folks, > >With regards my 68K-only application-in-progress, the error count is down > from 617 to 25. All the remaining errors appear linker-related. There > are two kinds of errors. > 1) "relocation truncted to fit: DISP16 _GccRelocateData[crt0.c]" >(or __do_bhook or __do_ehook or __do_ctors or __do_dtors...) > >and > > 2) "relocation truncated to fit: start[hooks.c]" (or DISP16 mulsi3...) > > Where might I inquire as to learn how to resolve these errors? It looks > like I am not including some important blob or am suffering from having > over-specified something. > > Thanks! > All these are from the C startup code which is linked in *after* all your code. These are called from the C library start() function which is the *first* function in the code 1 (.text) segment. Thus means there is still too much code in your main code section, so you'll need to move more functions to other sections untill these errors disappear. Read up on how to get a linker map in the prc-tools documentation. Also 'm68k-palmos-objdump -h' will show section sizes. HTH Ton van Overbeek -- For information on using the PalmSource Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: build-prc and Palm OS Debugger
On 2005-09-22, Eric Potter <[EMAIL PROTECTED]> wrote: > I'm building an app with the prc-tools. When I go to debug it with Palm > OS Debugger, it can't find any of the symbols. Is there something that I > need to pass to build-prc so that the debugger can find the symbols? Or > is it impossible to debug prc-tools based apps with the Palm OS debugger? > Works for me (with the standalone Palm OS Debugger). Open the Files tab in Palm OS Debugger (or select Window -> Files Window from the main menu) after you have loaded your prc in the debugger. You should have an Executables and Symbolics tree. Check that your source files are in the symbolics tree with Path spec. If not, you can add the path manually (just click on the file name). Main problems is that the COFF format does not store the complete path name of the source file in the object file. With sourc, object and prc files in the same directory it should work. And of course you need to both compile and link with '-g' option, otherwise nothing works. HTH Ton van Overbeek -- For information on using the PalmSource Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: build-prc and Palm OS Debugger
On 2005-09-22, Eric Potter <[EMAIL PROTECTED]> wrote: > I still do see my symbolics. > > I am calling m68k-palmos-gcc and build-prc with -g. Do I need to use it > anywhere else? > build-prc does not have a '-g' option. You need the -g option in the compile (m68k-palmos-gcc -c) and link stage of m68k-palmos-gcc. > Does it make a difference that prc is part 68k and part arm (linked with > Peallink)? > > In Palm OS debugger, I see my prc, but the Symbolics tree is empty. When > I right click on the symbolics node, I get an option to "Add Symbolics > File...", but I don't have an axf, elf, or psym file associated with my > project. You said I could add the source files by just clicking on the > file name. Can you elaborate on that? > In my previous post I was referring to a 68k only application. Peal does a lot of manipulation, so my guess is that the connection to the original arm symbolic information gets lost. I personally have no experience (yet) in debugging pno-lets compiled with arm-palmos-gcc. But for the 68k part it should work... Ton -- For information on using the PalmSource Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: After Resolving Segmentation Problem ,Float Value Error
On 2005-09-23, Jeetu <[EMAIL PROTECTED]> wrote: > I debugged it and ifound it is showing me the error in this Fn at > > FlpBufferAToF(result,"0"); > > Global declaration:- FlpDouble *result; > > I m Totally Confused any guesses what might could be the problem ? > Your result pointer has to point to something to store the result. Have you intialized your result pointer (e.g. FlpDouble myresult; FlpDouble *result = &myresult;) ? If it is not initialized, you have indeed an invalid pointer. HTH Ton van Overbeek -- For information on using the PalmSource Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Next Palm mobile using Windows? Palm press conf Sep 26 with Bill Gates
>From Palm's website, press room: --- Palm, Inc., Microsoft Corporation and Verizon Wireless Announce Press Conference for Sept. 26 SUNNYVALE, Calif.--(BUSINESS WIRE)--Sept. 23, 2005--Ed Colligan, Palm, Inc. (Nasdaq:PALM) president and chief executive officer; Bill Gates, Microsoft chairman and chief software architect; and Denny Strigl, president and chief executive officer of Verizon Wireless, invite the news media to join them for a press conference on Monday, Sept. 26, at The Palace Hotel in San Francisco beginning at 9 a.m. PDT. Admission will be limited to members of the business and technology news media who present current press credentials. Registration will begin at 8 a.m. outside the Twin Peaks conference room on the second floor of the hotel. RSVP --- For the full announcement see: http://www.palm.com/us/company/pr/news_feed_story.epl?reqid=760556 Ton van Overbeek -- For information on using the PalmSource Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: FrmSetNavState() woes
> Anyone have any ideas? I could sure use them about now... > In a similar situation I clear the navigation flags when I get the frmLoad event in the event handler for the modal form. Since you have your own event handler for the modal form, you could try that. Ton van Overbeek -- For information on using the PalmSource Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
USB VendorID and PeoductID for TX and Z22?
See subject. What are the USB VendorID and ProductID for the new TX and Z22? I suppose the VendorID is 0x0830 (Palm). I need this infor to update my tcp-usb bridge to (try to) support 68k debugging on the new devices. Thanks in advance. Ton van Overbeek -- For information on using the PalmSource Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: handspring sdk - where to find it?
On 2005-11-02, Guilherme C. Hazan <[EMAIL PROTECTED]> wrote: > Hi, > > In which program i have to be subscribed to download this sdk? I already > went to developerpavilion and searched for it without success. > > Basically, all i want to know is the value defined for > > hsVerStrSerialNo > > thanks > > guich > You need the Palm SDK (latest is 5.1) from the plugged in program: http://pluggedin.palm.com . hsVerStrSerialNo is defined in include file .../common/system/HsExtCommon.h . It is the 2nd element in an enum typedef, so you can figure out its value ;-). HTH Ton van Overbeek -- For information on using the PalmSource Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: PalmOSCygwin PODS and Cygwin
On 2005-11-02, Thom L <[EMAIL PROTECTED]> wrote: > My goal is gain the full functionality of my cygwin installation and use > PODS at the same time. > I've tried installing PODS with PalmOSCygwin and then trying to update the > cygwin install (updating the install directory to /palmoscygwin of > course) and have had failure with that. > > Has anyone had success getting PODS to work with a full version of cygwin? > > Has anyone found documents that would detail what the PODS installer needs > to do regarding cygwin? > > Thanks in advance, > > Thom > The simplest way IMHO is the following: First install Cygwin. Second install prc-tools from http://prc-tools.sourceforge.net . Third install PODS, and select a custom install. Select the option to *not* install the Cygwin included in PODS. I have been running like this since the first version of PODS while continuously updating my Cygwin installation. HTH Ton van Overbeek -- For information on using the PalmSource Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: PODS with custom Cygwin install
On 2005-11-12, Philip Pemberton <[EMAIL PROTECTED]> wrote: > Hi, >I'm trying to get the PalmOS Developer Suite working on my system. I > already had Cygwin installed, so I just installed all the packages listed in > the README. Problem is, if I create a new project, I get this error in the > Problems pane: >Error launching external scanner info generator (gcc -E -... > > Does anyone know what might be causing this? Cygwin is installed in > c:\cygwin, > and all the PRC-Tools dev.tools are accessible from the Cygwin bash-prompt. > > Thanks. Your bash login script probably sets up your path. PODS starts gcc directly and therefore uses the Windows path. Solution: make sure 'c:\cygwin\bin' is in the Windows path. You can check/change the Windows path by right-clicking 'My Computer' -> Properties -> Advanced tab and selecting the 'Environment Variables' button at the bottom. Have been running with my own Cygwin and prc-tools since the beginning of PODS. Ton van Overbeek -- For information on using the PalmSource Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: help with page UP/DOWN on Tungsten E2
On 2005-11-18, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Hello, > > Recently, we received reports that our products do not support > Page Up/Page Down of the 5-way navigator on the Tungsten E2 device. > > Page Up/Page Down, however, work on the E2 Simulator and we couldn't > reproduce the problem. > > Do you know the reason for this and how to resolve it? Any ideas? > Not all simulators are representative for the fiveway navigator. The keycode and flags generated can be different. I compared the codes generated by my TX with the codes generated by the TX debug simulator and they are different. This might also be the case for the E2. So you will have to debug on a real device or write a small program that reports the keycodes and flags generated by the fiveway and let yout user report the results. HTH Ton van Overbeek -- For information on using the PalmSource Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Copy PDB to \Palm\Launcher on SD card
On 2005-11-21, Doug Gordon <[EMAIL PROTECTED]> wrote: > My app's VFS support has been working for years, and I swear that I used to > transfer PDB files directly to the \Palm\Launcher directory on my SD card, > which is where my app looks for them. But the other day, I found that when my > app reads a file that was directly copied, I get a "Generic File Error" from > the VFSRead function even though my input parameters certainly look correct. > But if I Hotsync the same file to the card, everything works. > > It gets stranger. If I use McFile to delete the PDB file, McFile also reports > a "Generic file error" even though it does delete it. Just for fun, I copied > a couple of random PDB files to the \Palm\Launcher directory, and McFile had > the same error for all of them. But if I copy them someplace else on the > card, such as to the root directory, there are no errors. I also tried this > with two entirely different card-read/write devices, with the same results. > > I might mention that this is occurring on a T3, and that when I last tried > doing this sort of thing I might have been using my old M505 or Tungsten T. > Plus, if this were a widespread problem it seems that I would be hearing from > some customers. > > Any ideas, anyone? > > -- Doug G > -- For information on using the PalmSource Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Aging screen selectively lighter gray?
On 2005-12-04, Luc Le Blanc <[EMAIL PROTECTED]> wrote: > A user abroad tells me that on his OS 4.1 IIIxe, my application displays > its forms in a lighter shade of gray than others. He also notices that > with FileZ and a few apps, but says some other third party apps like > GPilotS appear as dark as the built-in ones. How can this be? Selective > screen fatigue??? Probably due to color -> grayscale conversion. The IIIxe has 4 bit 'color', i.e. 16 shades of gray. Only if the form used black it would show up as dark as the built-in ones. HTH Ton van Overbeek -- For information on using the PalmSource Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: prc-tools
In article <[EMAIL PROTECTED]>, geoff wrote: > i have installed cygwin and the problem is i dont tar and build commandsa > arent working > If you want a ready-to-run version of prc-tools for Cygwin use the Cygwin setup utility (no tar needed). Have you read the instructions on http://prc-tools.sourceforge.net/install/cygwin.html ? If you want to build prc-tools under cygwin on Windows XP it is assumed you know how to use make, gcc, configure, tar and all the other needed development tools. HTH Ton van Overbeek -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Repost: PODS 1.0 Beta, Debugging Multi-Section 68k apps does not seem to work
On my July 2 posting I did not get any reactions (probably due to the July 4 holiday weekend). So here the same message again: -- I am glad to see my patches for multi section debugging made it into PODS 1.0 Beta. However I cannot get multi section debugging to work with the Palm OS Debugger (POD). (tried the Memo sample from sdk-5r4). Am I overlooking something ? Or is this still on the todo list for the final version 1.0? Could the preview pmgdb (with my patches) be reused instead of PalmOSDebuggerMI ? I have used a custom install since I did not want to trash my own Cygwin installation which I also need for other things. I have been playing with the idea of providing a plugin for the multi section version of pmgdb, but I will have to learn a lot of things about eclipse and java. Is there some way to get debugging multi section 68K apps working inside PODS ? --- Can somebody confirm multi section 68k debugging is not working in PODS 1.0 Beta ? Ben ? Ton van Overbeek -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: How to use prc-tools
In article <[EMAIL PROTECTED]>, Yann Garcia wrote: > Hi, > > I'm trying to use PRC-Tools on Red-Hat 9.0 > I got the sample 'hello' and I try to compile it. I use the PalmOS sdk > 4.0. > The compilation failed with this two errors: > > m68k-palmos-gcc -palmos4.0 -Wall -g -c -o hello.o hello.c > m68k-palmos-gcc: unrecognized option `-palmos4.0' > In file included from hello.c:11: > /usr/share/prc-tools/include/PalmOS.h:12: #error No genuine PalmOS.h > found > /usr/share/prc-tools/include/PalmOS.h:15: warning: #warning use Pilot.h > if you really mean to use the 3.1 SDK or earlier; you may need to run > palmdev-prep or use a suitable -palmosN option -- see > "http://prc-tools.sourceforge.net/cgi-bin/info/palmdev-prep"; for details > make: *** [hello.o] Erreur 1 > > > Anyone can help me to understand what happen? Why gcc doesn't recognize > 4.0 SDK? > > Thanks a lot for your help. > > Cheers, > > Yann It looks like you did not read the instructions on post install activities for prc-tools in the documentation on the sourceforge site. Go to http://prc-tools.sourceforg.net/install/rpm.html which contains instructions for Linux installations. Read the Post-installation setup section. Hint: palmdev-prep. HTH Ton van Overbeek -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: MathLib and Palm with ARM Processor
In article <[EMAIL PROTECTED]>, Alexandre Estanislau wrote: > I have the Version 1.1. I?m using CW for PalmOS V8. Now, I downloaded the zip file > from http://www.radiks.net/~rhuebner/mathlib.html and I will try to compile it. > > If anyone have more ideas, please help me !!! Not really any more ideas. I have been using MathLib with EasyCalc (http://sourceforge.net/projects/easycalc) on both a Tungsten-T (OS 5.0) and T3 (OS 5.2.1) without any problems. EasyCalc is also a multi-segment application and uses the same code as you to open and close MathLib. The only thing I can think of is that something else trashes some datastructures used by System Libraries in the OS. When you do not use MathLib the trashed data is not used and hence no crash. Have you tried to run your code on a Debug version of the Pose or one of the 5.x Simulators? Could give you some warnings about illegal memory accesses. HTH Ton van Overbeek -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
PODS 1.0 available
Right now I am downloading the official Palm_OS_Developer_Suite 1.0 from PalmSource. Waiting for Ben's 'official' announcement on these forums ;-). Ton van Overbeek -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: help to get .elf file for PalmOsDebugger with PRC-Tools.
In article <[EMAIL PROTECTED]>, BrownB wrote: > Yes, i use -g flag, here is a piece of my makefile: > GCC=m68k-palmos-gcc.exe -Wmissing-declarations -g > > app.prc: app.def app.ro app > build-prc.exe -o app.prc app.def app app.ro > > app_segments.ld app_segments.s: app.def > m68k-palmos-multigen.exe -b app_segments app.def > > for each file of my project there's this line: > file.o: file.c file.h app_segments.s > $(GCC) -c $(basename $@).c app_segments.s > > the final link is this: > app: app_segments.ld $(OBJ) $(SRC) > $(GCC) -o app $(OBJ) app_segments.ld -lPalmOSGlue > > Then, everytime I call $(GCC) I do the work with the -g flag... > The problem remains: I can open "app.prc", append the COFF file "app" but can't see > any code... > > BrownB > Just a thought. Are you using POD included in PODS ? The previously released POD does not understand COFF symbol files. The COFF support was added specifically for PODS in order to support prc-tools output. Ton van Overbeek -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: C++ virtual methods with prc-tools
In article <[EMAIL PROTECTED]>, John Gruenenfelder wrote:
> I have a fairly large m68k project (Weasel Reader) that I've built with
> prc-tools 2.3.
>
> Recently, I've been rewriting some of the graphics code in a class framework
> to make my life simpler. Unfortunately, it seems that when one of my objects'
> destructors is called, the device jumps off someplace random on return from
> the destructor.
>
> For example, I have a pure virtual base class:
>
> class Widget {
> public:
> virtual ~Widget(void) { }
> virtual Boolean foo(void) = 0;
> };
>
> And an inherited class that does the work:
>
> class Bar : public Widget {
> Bar(void);
> ~Bar(void);
> Boolean foo(void);
> };
>
> Bar::~Bar(void)
> {
> // Nothing to do, just return
> }
>
>
> In my code, I create Bar via new, enter my event loop, then do some
> processing. When the user returns to the index form, the object is destroyed
> via delete. The destructor is run and all seems fine. When the destructor
> returns, it does *not* return to where it should.
>
> I should mention that the Bar class is in another code segment. If I place it
> in the default segment, my code works just fine. Of course, the default
> segment is just too small to hold these objects. I should also mention that
> the code calling Bar's destructor is itself in a different segment.
>
> What is going on? This is the first time I've used any C++ class stuff with
> prc-tools... are there any caveats I should be aware of? Specifically with
> multi-segment programs?
>
> This is with prc-tools 2.3 which I compiled myself in mid-January.
>
> One more note: When I say that the return jump from the destructor doesn't go
> to the correct place, I base that upon what I see in the debugger. GDB
> doesn't handle multiple segments well, but I have applied the Msect GDB
> patch... but I suppose it's possible that what I see in the debugger may not
> actually be correct.
>
> I'm confused...
>
>
I am afraid I cannot give much direct help, but only a few caveats:
- I have never tested my multisection debugging patches on 'real' C++
code, so there might be additional fixes needed for C++.
- Also, as you know, m68k-palmos-gcc is based on gcc-2.95.3 which predates
the C++ standard, so also there might be problems.
When I have some time (not very likely ;-)) I'll take a look at the weasel
reader code on sourceforge and see if there are any problems there with
running it through gdb.
By the way, is the code working without gdb, or crashing when returning
from the destructor?
Ton van Overbeek
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/support/forums/
Re: Palm Error: cannot open scrt0.o
In article <[EMAIL PROTECTED]>, Saurabh Agarwal wrote: > Hi, > > I am getting the following error when trying to compile my palm code using > prc-tools. > ERROR: > > /usr/m68k-palmos/bin/ld: cannot open scrt0.o: No such file or directory > collect2: ld returned 1 exit status > make: *** [MsgLib.lib] Error 1 > > My gcc version is: > > $ m68k-palmos-gcc -v > Reading specs from /usr/lib/gcc-lib/m68k-palmos/2.95.3-kgpd/specs > Reading specs from /usr/lib/gcc-lib/m68k-palmos/specs > gcc version 2.95.3-kgpd 20010315 (release) > > My Makefile is: > > # name of program > PROGRAM = MsgLib > > #The icon title of the application, on the palm > DESCRIPTOR= MSGA > > DEF = $(PROGRAM).def > > # C sources derived to: > OBJS = MsgLibDispatch.o MsgLibImpl.o InitGlobals.o Backup.o InitStruct.o > MsgLibInterface.o XD10p.o XD10.o Common.o ProcessRequest.o CBCommand.o > $(PROGRAM)-sections.o > > #The names of: the resource file, the library (which is built by make) > and the output > PROGLIB = $(PROGRAM).lib > PRC=$(PROGRAM).prc > > # compilers and linker > CC=m68k-palmos-gcc > AS = m68k-palmos-as > MAKELIB = $(CC) -shared -g -O1 -lgcc -Wmissing-declarations -Wall > -L/m68k-palmos/lib -Xlinker -Map -Xlinker $(PROGRAM).map -o > CFLAGS = -Wall -O2 -palmos4 > LINK = build-prc -o > > all: clean $(PRC) > > # to make the application xxx.prc > $(PRC): $(PROGLIB) $(DEF) > $(LINK) $(PRC) $(DEF) $(DESCRIPTOR) $(PROGLIB) > # make clean > > # to librarize those source(s) > $(PROGLIB): $(OBJS) > $(MAKELIB) $(@) $(OBJS) > > MsgLibDispatch.o: MsgLibDispatch.c > MsgLibImpl.o: MsgLibImpl.c > MsgLibInterface.o: MsgLibInterface.c MsgLibInterface.h > XD10p.o: XD10p.c XD10p.h > CBCommand.o: CBCommand.c CBCommand.h > InitGlobals.o: InitGlobals.c InitGlobals.h > Common.o: Common.c Common.h > ProcessRequest.o: ProcessRequest.c ProcessRequest.h > XD10.o: XD10.c XD10.h > Backup.o: Backup.c Backup.h > InitStruct.o: InitStruct.c InitStruct.h > > $(PROGRAM)-sections.o: $(PROGRAM)-sections.s > > $(PROGRAM)-sections.s: $(DEF) > m68k-palmos-multigen $(DEF) > > # clean-up functions > clean: > rm -f *.[oa] *~ $(PROGLIB) I do not know where you got your Makefile, but it shows the author not being well-versed with PalmOS programming. Your problem is still the MAKELIB step. In fact this step is not about making a library, but about doing the final link. Your final link step (using build-prc) is more a post-processing step to produce the prc from the output of the link and combining it with the other resources (typically the output of PilRC). There is no conventional shared library (.so in Unix/Linux .dll in Windows) in PalmOS so the -shared option to ld is not working. SysLibs and GLibs are the PalmOS equivalent, but require different steps to produce them. In the MAKELIB (again wrong name) step get rid of both the -nostartfiles and the -shared option. Hope this helps. Ton van Overbeek -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: serReceiveWindowOpen
In article <[EMAIL PROTECTED]>, jhillman1 wrote: > Richard Rhode of Palm support suggested I look at sample code using the > serReceiveWindowOpen. Below is a fragment of his message asking me to > try the code and where is it located. I cannot find any sample code at > the Plugged In web site. > > Does anyone know about sample code using serReceiveWindowOpen. I've > attempted to make it work, but I get the same result as using the > srmReceive, but maybe I am using it wrong. > > --message from Palm support---($200 worth???)- > > 2. Has the developer tried the sample code provided by palmOne on PluggedIn? > (It uses SrmWindowOpen instead of the SrmReceive. It seems to work on Zire 72.) > > http://pluggedin.palmone.com/regac/pluggedin/index.jsp > -- > I suppose the sample SrmReceiveWindowOpen code is the one in the IRCommunication sample code which is part of the PalmOne SDK v3.0. You have to be a registered developer at PalmOne to download this SDK. HTH Ton van Overbeek -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: ARM compiling
In article <[EMAIL PROTECTED]>, BrownB wrote: > Hello, I'm trying to compile a native ARM function using arm-elf-gcc, but I can't: > the compiler can't find the "include" dir, which contains PalmOS.h and the others > headers of the sdk-5r4. > > I used the -B option in a script: > > arm-elf-gcc.exe -O1 -B"$INCLUDE_PATH" -Wall -Wmissing-prototypes > -Wmissing-declarations -nostartfiles -nostdlib -nostdinc -fno-builtin -fPIC > -ffixed-r8 -ffixed-r9 -mpic-register=r10 -msingle-pic-base -c "$1" -o "$OUTFILE" > > where $INCLUDE_PATH is: > INCLUDE_PATH=PalmDev/sdk-5r4/include/ ^ If this is not a typo, you are missing the leading / in INCLUDE_PATH. As it is written here it is relative to the current directory. > > the error is that the compiler can't find the included file PalmOS.h > > Can anyone help me? > BrownB > HTH Ton van Overbeek -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: How to manually install the PRC-tools.
On 2004-10-12, mikl <[EMAIL PROTECTED]> wrote: > Hello, > > I am already using cygwin for different kind of development, and I need to install > properlly the different directories of the prc-tools into the pre-install cygwin > directory. > > FYI : I am not using the setup.exe installer provide by red-hat to install cygwin > (thus I can't install prctools by the setup.exe installer) and I am not using Linux > neither. > > Thx > If you do not want to use Cygwin's setup.exe here is what to do: Get the prc-tools-2.3-cygwin.tar.bz2 file from the sourceforge downloads page (http://sourceforge.net/project/showfiles.php?group_id=4429). This is assuming you only need the 68k tools. The tar contents puts everything into standard places. The filepaths in the tar file are not absolute (= they do not start with /). So the normal way to extract in a cygwin shell: (cd /; tar jxvf /prc-tools-2.3-cygwin.tar.bz2) If you need them in different places, it gets more complicated. You will have to unpack the tar.bz2 to some place and copy/move the individual files separately. However gcc expects to find its componente in standard places, so this will probably not work. HTH Ton van Overbeek -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: How to manually install the PRC-tools.
On 2004-10-13, mikl <[EMAIL PROTECTED]> wrote: > Hi > > Thx for your answer... > > But I must admit that there is something weird around this, because, when I > look into the tar.bz2 file, I see that there is a /usr main dir and > then, /usr/bin, /usr/doc, /usr/info ,... subdirs.. > > But When I look at the PODS installation, the binaries (I mean > m68k-palmos-gcc.exe and others) are stored into the /bin main directory > of cygwin... > > 1. Why such a difference ? > With a standard Cygwin installation /bin and /usr/bin are the same directory. This is due to the Cygwin mounts. Partial output fromCygwin mount command on my system: C:\cygwin\bin on /usr/bin type system (binmode) > Obviously, if I just unpack the tar.bz2 file into cygwin, my PATH variable > would not be able to point to the binaries... > > 2. So is there any documentation of what should be where ? > > 3. Does the bin dir is the only exception and all the other just need to be > into the /usr dir of cygwin ? > Yes. See above. -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Size of a segment
In article <[EMAIL PROTECTED]>, Dominique wrote: > You can also look at you map file, if you generate one. > > "Remi Ricard" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] >> Hi Matt, >> >> >>> If you're also using Windows, you can use PRCExplorer. >> >> Thanks for the info. >> >> Remi The easiest way to look at segment/section sizes when using prc-tools is to use the m68k-palmos-objdump utility included in prc-tools. Here for example is the output for the Memo example of the sdk-5r4 in PODS 1.1 preview: --- $ m68k-palmos-objdump -h memo memo: file format coff-m68k Sections: Idx Name Size VMA LMA File off Algn 0 .text 5a90 0120 2**2 CONTENTS, ALLOC, LOAD, CODE 1 .data 033c 5bb0 2**2 CONTENTS, ALLOC, LOAD, DATA 2 .bss 0030 033c 033c 2**2 ALLOC 3 code1 1404 5eec 2**2 CONTENTS, ALLOC, LOAD, CODE 4 code2 068c 72f0 2**2 CONTENTS, ALLOC, LOAD, CODE 5 .reloc00b4 797c 2**2 CONTENTS, ALLOC, LOAD --- Use 'm68k-palmos-objdump --help' for more options or if everything else fails read the documentation. HTH Ton van Overbeek -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: PRC-tools problem
On 2004-10-08, Thomas Okken <[EMAIL PROTECTED]> wrote:
>> A kind soul suggested linking using Multilink (http://djw.org/).
>> I'll try that next and post a message later on to report how I got
>> on. (I'm off for a one-week vacation in a couple of days so it may
>> only get done after I get back.)
>
> I couldn't resist after all, so I went ahead and downloaded Multilink.
> I'm glad I did; building and installing it, and modifying my project to use
> it, were pretty straightforward and the required steps are well documented.
> I had it all up and running in half an hour, and I'm happy to say that
> the operation was a complete success! Gdb can find functions in all sections
> now. :-)
>
> My development machine is a PC with plain vanilla Red Hat Linux release 7.3
> installed, with the full set of development tools and libraries (I use
> it for Java and Unix/Motif development as well as for the Palm stuff).
> For Palm development, I installed palmos-sdk-5.0r3-1.noarch.rpm,
> prc-tools-2.3-1.i386.rpm, pilrc-3.2-1.i386.rpm, palmos-sdk-5.0r3-1.noarch.rpm,
> and of course POSE, all obtained from the usual sources (PalmSource and
> the PRC-tools project page on SourceForge). I downloaded Multilink and the
> Palm version of the BFD library from http://djw.org/product/palm/multilink/;
> I installed the BFD library and the header file under
> /opt/palmdev/sdk-5r3/; in the Multilink Makefile, I changed PILOT_DIR to
> point to that directory, and then I typed 'make' and multilink built without
> a hitch. I ran "make install" as root and allowed it to install it to
> /usr/local/bin, which was in my PATH already.
>
> The steps required to change the linking and PRC building steps of the build
> process are well explained in the documentation included with Multilink.
> I had my Makefile fixed in minutes; all I had to do in my source code
> was to change the definitions of the section macros from
> __attribute__ (yada yada yada) to nothing, which was easy because I had
> them all in one place (I build an X11 version of the project from the
> same sources so all the PalmOS-specific stuff was conditional to begin
> with).
>
> When running gdb (or in my case ddd with gdb underneath, but that makes no
> difference), there are two extra steps involved: loading the script file
> generated by multilink ("source ") and then running it
> ("load-segments") after gdb has connected with POSE.
> From that point onward, it's business as usual -- well, better than usual,
> really, because now gdb can find all functions in all segments once
> again, so you can go back to debugging code instead of tearing out your
> hair.
>
> Many thanks to Eric House for pointing me in the right direction, and to
> David Williams for making this nifty tool available to the general
> public. You've rescued my project!
>
> - Thomas
Apologies for coming late in this thread.
Are you aware of my patches for multi-section debugging ?
See http://www.v-overbeek.nl/msectgdb for details.
Multilink is nice, since it tries to do all the sectioning for you.
The stock m68k-palmos-gdb will find the functions (as you noticed), but
there are problems when stepping through the code and the step takes you
from one section to an other. (m68k-palmos-gdb does not understand the
trampoline code which multilink uses).
My patches work fine for your original sectioning code (using
__attribute__ (yada)) and has no problems with stepping into a different
section.
If you are happy using multilink, please continue using it. But I thought
you might want to know that there also is an other way to solve your
problem.
HTH
Ton van Overbeek
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/support/forums/
Re: "ld region coderes full" Please help
On 2004-10-21, Ben Combee <[EMAIL PROTECTED]> wrote:
> At 09:57 AM 10/21/2004, you wrote:
>>There is some very good information in here! Thanks for the pointer. I
>>tried compiling with the -T text_64k sample file I got he following error:
>>undefined reference to '_text_'[gdbstub.c].
>>
>>I then tried just a hello world app with the same -T option and got the
>>same result. So my question is now, beyond additional cose optimizations
>>(and those are great ideas in the article) how does one build a linker
>>script to get rid of the coderes full error?
>
> AFAIK, there's a problem with the test_64k script and the changes made to
> PRC-Tools to support multiple-section debugging. However, you shouldn't
> need to use text_64k if you've properly sectioned your code, although it
> might be required if you've got a large enough section of code that has to
> be in place during non-global launch codes.
>
>
> -- Ben Combee, Technical Lead, Developer Services, PalmSource, Inc.
> "Combee on Palm OS" weblog: http://palmos.combee.net/
> Developer Fourm Archives: http://news.palmos.com/read/all_forums/
If you want to use the text_64k script, here is a fix:
In the text_64k file (normally installed in /usr/m68k-palmos/lib/text_64k)
you need to add one line to the .bss definition:
Original version:
.bss :
{
bss_start = .;
*(.bss)
*(COMMON)
} > datares
Changed version:
.bss :
{
bss_start = .;
PROVIDE(__text__ = .);
*(.bss)
*(COMMON)
} > datares
That should get rid of your linker error.
I will include this in the next version of my patches.
Thanks (indirectly) for the bug report.
By the way, same change is needed for
/usr/m68k-palmos/lib/text_64k_palmos3
Ton van Overbeek
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/support/forums/
Re: PODS: C++ application segmenting (once again...)
On 2004-10-26, Thomas Werner <[EMAIL PROTECTED]> wrote: > Hi there! > > I apologize for contributing once again a question about application > segmenting, but even after reading through several forum postings, > articles etc. about this topic, I still do not get how to accomplish > this task under the PalmOS Developer Suite v1.0.0. > > I'm currently writing an object-oriented game framework (68K PNO Project) > which already exceeds the code resource limits. > So my question is - how to handle this with the tools, PODS provides? > > I generally understand, that (C-)functions need to be cut into "smaller > pieces". But I'm not sure how to do this with a C++ app. Does it also > apply to an object's methods? > > Maybe I am dense, but I do not fully understand the explanations from the > PRC-Tools site > (http://prc-tools.sourceforge.net/doc/prc-tools_3.html#SEC20). > Besides that, the project's make-file tells in the first line: > "This file auto-generated by Palm OS Make builder. Don't modify > directly!!!" > > So what shall I do? > > Many thanks in advance! The PRC-Tools site documentation on sectioning the code only applies to 68K code. There is no such limitation for PNO. However there is an other limitation for PNO's due to the Hotsync limit of 64k per resource (at least for pre Cobalt versions of Hotsync). CodeWarrior has a PNO loader which takes care of this. For PODS/PRC-Tools/PalmSource ARM compiler you will need to do that yourself. So is your segmentation needed for the 68k part or for the PNO part? Ton van Overbeek -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Palm OS Developer Program
On 2004-12-22, Ben Combee <[EMAIL PROTECTED]> wrote: > At 09:18 AM 12/22/2004, you wrote: >>Looks like that they are having problems with this new provider. >> >>be patient, probably they are still migration subscriptions from the other >>base. >> >>There are developers that are in worst situation compared to you like me >>that can not login! > > I am collecting all the feedback from the developer forum and passing it on > to the people who worked on this transition. Hopefully, I'll be able to > provide more information later today. > I also had to go through 'the request temp password and change it' routine on the new site. My personal data in 'My Account' were correct, so they seem to have transferred OK. One other issue: the (partial) PalmOS source code for PalmOS up to 4 are nowhere to be found any more. Will they be availabel again ? Second other issue: PalmSource changes for PODS 1.1 still not available, only the changes to prc-tools for PODS 1.0 are there. Ton van Overbeek -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Palm OS Developer Program
On 2004-12-22, Ben Combee <[EMAIL PROTECTED]> wrote: > >>One other issue: the (partial) PalmOS source code for PalmOS up to 4 >>are nowhere to be found any more. Will they be availabel again ? > > We didn't get the developer agreements transferred to the new developer > accounts yet. I don't know yet if this will be its own click-through > agreement, or if it will be part of a new developer section we're setting > up to handle seeding access. However, if you've already downloaded the > source, you can continue to refer to it. > >>Second other issue: PalmSource changes for PODS 1.1 still not available, >>only the changes to prc-tools for PODS 1.0 are there. > > I still don't have access to the new site to upload or update the files; I > learned that the transition went live when I read the postings on the forum > this morning. I'm working on getting access. In the meantime, you can get > the source packages from a mirror I setup on my own site at: > > http://palmos.combee.net/dl/original_sources.zip > http://palmos.combee.net/dl/pxgdb-6.0-psi.zip > http://palmos.combee.net/dl/src_CDT_2.0.2_modified.zip > http://palmos.combee.net/dl/prc-tools-2.3-psi.zip > http://palmos.combee.net/dl/sources_readme.txt > > I hope to get this resolved soon, but PalmSource will be shut down next > week for the holidays, and already a lot of people have left for vacation > (including me -- I'm writing this from my parents' house). > I already got them from your site the first time you posted. Ben, enjoy your holidays and do not worry too much about this until January. Ton van Overbeek -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: MultiSegmenting Debuggin Problem :-((
On 2005-01-25, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > I'm attempting to do some work on Palm Application program, using prc-tools > 2.3-2. Because of the size of the program, I've been forced to organize the > project as a multi-segment app. > > It appears that GDB doesn't know what to do with code that isn't in the main > code segment. I can set a breakpoint in a function in another segment, > but it never fires. I also can't step into the function -- it just > steps over it.I try to find on it but invain. > > Does anybody have any experience with this? What have you done to get around > the problem? My only thought so far is to rearrange the code when I'm > debugging so that the appropriate functions are in the main segment. > That could get tedious though. > > Thanks for any help, > Chintan. Dhruva This is documented in the prc-tools documentation. See http://prc-tools.sourceforge.net/doc/prc-tools_5.html Section 5.2 last sentence: At present, GDB won't work well with applications with multiple code resources. I have made patches to prc-tools to make multi-section debugging possible. See http://www.v-overbeek.nl/msectgdb for details. HTH Ton van Overbeek -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: segmentation again...!!
On 2005-02-15, BrownB <[EMAIL PROTECTED]> wrote: > Hello, I'm sorry to bother you with another question on this widely discussed > feature, > but I can't reach any progress and can't find any soultion path.. > > I'm using PRC-Tools. > > I was creating a library for my app, but I've reached the .text segment max > size and can't > move more functions to other segments. > > So I created a "plugin" application to be called from my main application: in > this way I > was starting with a "blank" .text section. I'm including some GC++ object > files I made > in the past in the link step. > > Now, I can't understand why I still get the overfill .text section error: > > m68k-palmos-g++.exe -o interpretation main.o MemUtils.o ht_ClassInterp.o > Ht_cmpl > x.o Ht_PqRsT.o interpretation_class_wrapper.o > interpretation_plugin_interface.o > segments.o segments.ld -lPalmOSGlue > /usr/m68k-palmos/bin/ld: region coderes is full (interpretation section .text) > /usr/m68k-palmos/lib/crt0.o(.text+0x50): In function `start': > crt0.c:64: relocation truncated to fit: DISP16 __do_bhook > /usr/m68k-palmos/lib/crt0.o(.text+0x5a):crt0.c:67: relocation truncated to > fit: > DISP16 __do_ctors > /usr/m68k-palmos/lib/crt0.o(.text+0x70):crt0.c:72: relocation truncated to > fit: > DISP16 __do_dtors > /usr/m68k-palmos/lib/crt0.o(.text+0x7a):crt0.c:74: relocation truncated to > fit: > DISP16 __do_ehook > /usr/m68k-palmos/lib/libcrt.a(hooks.o)(.text+0x16): In function `__do_bhook': > hooks.c:28: relocation truncated to fit: DISP16 start > /usr/m68k-palmos/lib/libcrt.a(hooks.o)(.text+0x64): In function `__do_ehook': > hooks.c:44: relocation truncated to fit: DISP16 start > /usr/m68k-palmos/lib/libcrt.a(hooks.o)(.text+0xa6): In function `__do_ctors': > hooks.c:60: relocation truncated to fit: DISP16 start > /usr/m68k-palmos/lib/libcrt.a(hooks.o)(.text+0xe0): In function `__do_dtors': > hooks.c:76: relocation truncated to fit: DISP16 start > /usr/m68k-palmos/lib/libcrt.a(multi_dreloc.o)(.text+0xe): In function > `_GccLoadC > odeAndRelocateData': > dreloc.c:56: relocation truncated to fit: DISP16 start > collect2: ld returned 1 exit status > make: *** [interpretation] Error 1 > < ... snip ...> > > You can see that the .text total sie is this: > > TOTAL TEXT SEGMENT SIZE: 0x3F34 = 16.180 > > So why this problem? I'm linking only PalmOSGlue.a. > > If anyone has any hint I'd appreciate it, thanks! > BrownB You forget the size of the system library routines (both C++ and C) which push you over the limit. In the the linking phase use the linker trace option (m68k-palmos-g++.exe -Wl,-t -o ...) to get a list of object files including those from libraries as they are processed. You can also get a linker map using the -Wl,-M option. See the man pages of gcc, g++ and ld for more details. Note that the default linker script only allows 32K in the .text segment. You can use your own linekr script to got to 64K, but you have to be carefull with intrasegment jumps (still need to be less than 32K). HTH Ton van Overbeek -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Fw: m68k-palmos-gcc: Palm OS SDK requested via -palmosN could not be found
On 2005-02-24, Jennifer Fell <[EMAIL PROTECTED]> wrote: > Hi Everybody, > > I am having the following error while trying to compile a project from a > makefile: > > m68k-palmos-gcc: Palm OS SDK requested via -palmosN could not be found > make: *** [Release/main.o] Error 1 > > What am I doing wrong? How do I fix it? It seems like it is looking for the > SDK directory (which was installed in "C:\Program Files\PalmSource\Palm OS > Developer Suite\sdk-5r4" when I installed the PODS). > > Also, I did try the palmdev-prep tool (as bellow) and then tried to compile > the project again, but still it didn't work: > palmdev-prep --default sdk "C:\Program Files\PalmSource\Palm OS > Developer Suite\sdk-5r4" > > Please advise. Thanks a lot in advance. > > Regards, > Jenni > palmdev-prep is a Cygwin application and thus expects Unix style paths. The argument for the --default switch should be sdk-5r4, *not* sdk. What is the output of 'palmdev-prep -v' ?? See http://prc-tools.sourceforge.net/doc/prc-tools_6.html#SEC37 for more info on palmdev-prep. Your path as Cygwin path would be: "/cygdrive/c/Program\ Files/PalmSource/Palm\ OS\ Developer\ Suite/sdk-5r4" HTH Ton van Overbeek -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
New version of multi-segment GDB patch: Works with PalmOS 5 Simulator
I have uploaded a new version of my multi-segment debugging patches for prc-tools-2.1: MsectGdb2.1-2. Changes since original 2.1 patches (MsectGdb2.1): - Changed logic in the blockvector resorting in objfile_relocate. The original logic was wrong and made gdb commands like 'info functions' produce the wrong results. Also setting breakpoints directly on functions did not work reliably. This problem was also present in my original prc-tools-2.0.91 patches. Both problems should be solved now. - Changes in remote-palmos.c: a) to make it possible to use m68k-palmos-gdb with the PalmOS 5 Simulator b) and the PilotMain breakpoint now generates a SIGSTOP when running on a real device and on the PalmOS 5 Simulator. Details on the remote-palmos.c changes: The PalmOS 5 Simulator sends bogus exception numbers in its state packets. Ignoring the exception number in remote-wait caused the first breakpoint (the DebugBreak from gdbstub) to be recognized. PalmOS 5 Simulator wants 'good' values for both the user and supervisor stackpointer (USP and SSP). In the state packets they are always equal for Palmos 5 Simulator (as far as I can tell). On a reali m68k device they can differ. Sending garbage value for the one not used in the resume packet causes the PalmOS 5 Simulator to crash. On a real device and on POSE it does not matter. The PilotMain breakpoint does not generate a SIGSTOP on a real device and on the PalmOS 5 Simulator. It turns out that the breakpoint address for the temporary breakpoint is already cleared in the status debug packet both on a real device (Palm IIIc/PalmOS 4 in my case) and on the PalmOS 5 simulator. Why it is there on POSE I do not know. Saving the temporary breakpoint address inside the module solved that problem. This version can be found in the ususal place: http://www.tvoverbe.cistron.nl/mseggdb/ Binaries: MsectGdb2.1-2.tar.bz2 Sources: MsectGdb2.1-2Patch.tar.bz2 Enjoy. Ton van Overbeek -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Linux version of multi segment GDB patch available
I finally found the time to generate Linux binaries of my multi-segment GDB patches. They are now available in MsectGdbLinux2.1-2.tar.bz2 on http://www.tvoverbe.cistron.nl/mseggdb. The patches themselves have not changed. I only updated the README. That is the reason also MsectGdb2.1-2Patch.tar.bz2 is updated (only change is the updated README). I have tested the Linux version with the small multiapp from prc-tools-samples and with a large application: EasyCalc from http://sf.net/projects/easycalc. The combination DDD/m68k-palmos-gdb/pose works quite well on Linux. Enjoy. Ton van Overbeek -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
New version (MsectGdb2.1-3) of multi-segment debugging patch available
A new version (MsectGdb2.1-3) of my multi-segment debugging patch for prc-tools-2.1 is now available. You can find it at (Note: new URL): http://www.v-overbeek.cistron.nl/mseggdb Gdb with these patches applied will identify itself as 'GNU gdb 5.0-tvo-20020729'. This version should solve (I hope) some of the problems people have noticed with large multi-segment applications, especially with several source files containing code for more than one code section. I also fixed something which has annoyed me for a long time: The PilotMain breakpoint did not break at the first executable line of the PilotMain() function. Now it does. >From the README file: Changes since MsectGdb2.1-2 - Changed symbol look-up code. In the case of code from several code sections in the same source file (e.g. static functions without a section attribute and public functions with a section attribute) the symbol look-up code could choose the symbol table of the wrong source file. This resulted in wrong function names reported or not stopping at a breakpoint at all. This should be fixed now. - Changed setting of PilotMain breakpoint. The original code did set the breakpoint at the address PilotMain+4, which is (in most cases) in the middle of the function prologue. Now the breakpoint is set at the first executable statement after the prologue, i.e. at the start of the first executable C code line. This also means the line number reported at the break is now really the first executable line of PilotMain, and not the last line before PilotMain. Comments, criticism, questions welcome. Enjoy. Ton van Overbeek, [EMAIL PROTECTED] (Note: new email address) -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
ANN: Multi-segment patch for prc-tools-2.2 available.
A first version (MsectGdb2.2-1) of my multi-segment debugging patch for prc-tools-2.2 is now available. You can find it at: http://www.v-overbeek.cistron.nl/mseggdb Gdb with these patches applied will identify itself as 'GNU gdb 5.0-tvo-20020824'. >From the README file: Changes since MsectGdb2.1-3 - Prc-tools-2.2 changed m68k-palmos-ld to use an internal linker script instead of an external linker script specified in the gcc specs file. Hence the change to the linker script (provide a linker symbol for __text__) in the multisegment patches moved also from gcc to binutils. - Because of the change to using an internal script the linker does not produce the expected order of segments in the linker output in the multi segment case. This is fixed by modifying the extra linker script produced by m68k-palmos-multigen. - Removed patches to work with PalmOS 5 Simulator and to stop at first executable line of PilotMain, since they are already included in prc-tools-2.2. Comments, criticism, questions welcome. Enjoy. Ton van Overbeek, [EMAIL PROTECTED] -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: PRC-Tools SDK
Ezekiel Sanborndeasis <[EMAIL PROTECTED]> wrote: > > There is now an unofficial Palm OS 5 SDK for PRC-Tools available as an RPM > package, tarball (headers anf static libraries) and zip (just the > libraries). Note that it is unsupported in that it was not developed or > tested by PalmSource Inc. The three downloads were graciously put > together by John Marshall with support from PalmSource. For more > information regarding PRC-Tools please see the PRC-Tools page at: > http://prc-tools.sourceforge.net/ > > -Ezekiel Sanborn de Asis Good news for prc-tools users. Question to John. What is the difference with the sdk-5 libraries included with FalchNet DevStudio 2.7 (except for extra mown-gp versions of libNetSocket.a and libNetSocket-debug.a) ? Ton van Overbeek -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: gdb & POSE, sigstop?
Michael Harrison <[EMAIL PROTECTED]> wrote: > > Ok, I've RTFM, trolled all the dev newsgroups, searched on google and > I can't find a method of disabling the SIGSTOP signal without messing > up gremlins. > > I'm running on Windows 2000 with the latest release version of the > prc-tools package. > > If I don't "handle SIGSTOP noprint" I'm constantly having to "cont" > when I'm running gremlins and gdb at the same time. > > If I do disable the print of SIGSTOP I constantly have to click > "resume" when gremlins does a find (which I don't have to do > normally). > > How can I just run a gremlins session and have gdb break if my program > crashes but need no input otherwise? > The command you need is "handle SIGSTOP noprint ignore". But if you want symbolic information, then you better give this command after the first SIGSTOP break at PilotMain. Ton van Overbeek -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: New version (MsectGdb2.1-3) of multi-segment debugging patch available
Michael Harrison <[EMAIL PROTECTED]> wrote: > I've been trolling the newsgroup looking for information on debugging > with gdb and programs with multiple segments and noticed a number of > independent patches for gdb to allow multi-segment debugging. > > Do you (or anyone) know if these patches have been incorporated into > the official distribution and if not, why not? No, they are not in the official prc-tools distribution (yet). John Marshall has been busy on the gcc side of prc-tools: providing ARM support, keeping up with binutils, and also preparing the m68k side for changeover to gcc-3.2. As far as I know there is also an overhaul pending for gdb. I am still waiting for John to release his new remote-palmos.c which has a different approach to getting the addresses of the various segments across to gdb. So for now you will have to live with separate patches. Note that my most recent patch is against prc-tools-2.2. I hope John wil correct me if anything above is not correct. Ton van Overbeek -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: gcc, search & section problem (repeat)
Michael Harrison <[EMAIL PROTECTED]> wrote: > (my apologies if this is the third copy of this message, I've been > having difficulty posting to the list) > > I've recently had to divide my first palm app into two sections and > was suprised to discover that when I initiate a find (which my app > supports), my application would crash during a call to a function that > wasn't in the default section. > > Has anyone else run into this problem (and documented it someplace I > haven't been able to locate)? > > If Yes, did you find a solution other than merely making sure that > your search function only called routines in the default segment? > This behaviour is documented in very many places, When your application is called with a non-standard launch code (as in find) global variables are not available. At least in gcc compiled programs, you need globals available in order to call functions in code sections 2 and higher. So the golden rule is: for all non standard launch codes do not rely on globals and do not call any functions outside the default code segment. PilotMain has to be in the default code segment. >From section 3.2.1 of the prc-tools documentation (http://prc-tools.sourceforge.net/doc/prc-tools_3.html): - The current implementation puts pointers to the code resources into the application's global data, and uses those pointers in the code emitted for each call in which the calling function and the called function are in different sections. This means that you must not attempt to call between different sections when globals are not available. In particular, all functions in your application called while processing a launch code that doesn't give you globals must be in the main code section. This always includes PilotMain, which is always called by the startup code for all launch codes. - You will find similar things in the PalmSource Documentation. E.g. in the Palm OS Companion section Responfing to Other Launch Codes: - In most cases, when you respond to other launch codes, you are not able to access global variables. Global variables are generally only allocated after an application receives sysAppLaunchCmdNormalLaunch (see Listing 2.2) or sysAppLaunchCmdGoto; so if the application hasn't received either of these launch codes, its global variables are usually not allocated and not accessible. In addition, if the application has multiple code segments, you cannot access code outside of segment 0 (the first segment) if the application has no access to global variables. ------------- In other words, when everything else fails, read the manual ... Ton van Overbeek -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
New version of multi-segment gdb patch (MsectGdb2.2-2) available
A second version of my multi-segment debugging patches for prc-tools-2.2 is now available: MsectGdb2.2-2. Gdb with these patches applied will identify itself as 'GNU gdb 5.0-tvo-20021118'. Changes since MsectGdb2.2-1 - Functions with inner blocks not in the default code segment were not treated correctly by ld and gdb. The start and end addresses of the innerblocks got messed up. This created havoc in the symbol lookup code creating things as references to wrong line numbers, source files and functions when stepping into a function in an extra code segment which contains inner blocks. This should be fixed now. Thanks to Andrew Razuwaev, who provided his code which made me squash this bug. You can find it at http://www.v-overbeek.cistron.nl/mseggdb. Enjoy. Ton van Overbeek -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Debugging not working any more ... I'M STUCK
Jan Bergquist <[EMAIL PROTECTED]> wrote: > > I am trying to write a Palm program, and now have reached about 14k. > It has been working fine with the gdb debugger, but now, suddenly, I can't > debug anymore: > > An example output when I run normally from the very beginning: (and after > some steps, 'continue' gives similar error lines, and doesn't continue) > > (gdb) s > 230 error = RomVersionCompatible (sysMakeROMVersion(3, 0, 0, 0, > 0), > launchFlags); > (gdb) s > Too many break points, break point not installed > warning: Cannot insert breakpoint 0: > Error accessing memory address 0xbb184: Operation not permitted. > (gdb) s > RomVersionCompatible (requiredVersion=50331648, launchFlags=142) at > Utils.c:102 > 102 UInt32 romVersion = GetRomVersion(); > (gdb) > > Anybody recognize this, and can give me some tips? > > (I don't have to add, that I am very new to this...) > This is usually caused by breakpoints which remain set in the emulator (or device) after a previous run. POSE (and real devices) can only handle 5 normal breakpoints and one soft one. In POSE check the setting of 'Settings->Properties' Closing/Quitting. If you save the session, it will be saved with the breakpoints you set during the session. You can delete the breakpoints via 'Settings->Breakpoints'. On a real device you will need to do a soft reset to get rid of previously existing breakpoints. Hoppas det hjaelper. Ton van Overbeek -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: I really love Multilink :)
I just read the flurry of postings on Multilink. Here are my 2 cents worth based on trying to adapt my multi-segment gdb patch to multilink 0.3. - As Chris Faherty pointed out, you need to patch the gdb add-symbol-file command to make it understand the expressions used in the script produced by multilink. - Even with this patch, there are still problems. All the data segments of the individul a.out files overlap, creating confusion for the data definitions in gdb. - The multilink calling sequence destroys registers a0,d0,d1,d2. Certain gcc runtime routines do not expect this. This will cause problems if they are called from a different segment. - With prc-tools-2.2 (a5 based globals access) the availability of globals is as usual: i.e. in non-global launch codes they are not available and hence intersegment are not guaranteed to work (a5 may point anywhere). Multilink is a usable tool to automate the multi-segmenting, but it is not full proof in every situation. Ton van Overbeek -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: I really love Multilink :)
Blake Winton <[EMAIL PROTECTED]> wrote: > The ability to tag each function, while useful, is at too low a level > of granularity for me (and Florent) to use, so I've been using > Multilink. (I've got a patch for the libraries it comes with, so if > anyone is going to start maintaining it again, please email me for > that.) I am very appreciative of the work that has gone in to the > prc-tools, and since I haven't the skill to contribute, I'm want to > make sure that people know that I'm not complaining, merely suggesting > further directions the functionality might take to be more useful to > me and the programmers I work with. Since I did some hacking on the gdb-multilink combo I would be interested to look at your patch. However multilink 0.3 does not come with any libraries. What libraries are you patching ? Regards, Ton van Overbeek -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
MsectGdb2.2-3 available
A new version of my multi-segment debugging patches for prc-tools-2.2 is now available: MsectGdb2.2-3. Gdb with these patches applied will identify itself as 'GNU gdb 5.0-tvo-20021223'. Changes since MsectGdb2.2-2 - Fixed a bug which made gdb skip the PilotMain breakpoint for an application with 10 or more code segments. Thanks to Steve Wetherill for tracking down this one. All files (patch source, cygwin and linux binaries) are available at http://www.v-overbeek.cistron.nl/mseggdb/ Enjoy, a merry Xmas and best wishes for 2003. Ton van Overbeek, [EMAIL PROTECTED] 2002-12-24 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: heap dump - GDB
Stephan Veigl <[EMAIL PROTECTED]> wrote: > > There is a heap dump command "hd" for the CodeWarrior debugger. Is there a > similar command for the GDB? > Short answer: No. If you check with turning the POSE low level log options on what actually is happening when a "hd" command is given, then you see a number of RPC (Remote Procedure Calls) calls passing by. These are documented in the debugger protocol. I have seen this using PalmDebugger. I suppose CodeWarrior uses a similar approach. As far as I know there is no direct support for the "hd" command in the Palm ROMs. So you/someone could write a "hd" command to be added to gdb Ton van Overbeek -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: multisegmenting troubles
Rick Reynolds <[EMAIL PROTECTED]> wrote: > > I've been using multilink to build up my app, and it has been working well > up to now. However, since debugging multilink'd apps in pose has problems, > I'm now trying to make the switch over to the gcc segmenting scheme. > > I have declared 7 code segments for my app. I have made the proper entries > in a .def file. I am using macros to declare the segments on the prototypes > for my functions. I have used -Wall to find all the functions that are > being used without a proper prototype and have fixed all of those. So I > believe that I'm building my app into specific code segments. I get the > following output at link time: > > /usr/m68k-palmos/bin/ld: region coderes is full (myapp section .text) > > /usr/m68k-palmos/lib/crt0.o: In function `start': > crt0.c:62: relocation truncated to fit: DISP16 _GccRelocateData > crt0.c:64: relocation truncated to fit: DISP16 __do_bhook > crt0.c:67: relocation truncated to fit: DISP16 __do_ctors > crt0.c:72: relocation truncated to fit: DISP16 __do_dtors > crt0.c:74: relocation truncated to fit: DISP16 __do_ehook > /usr/m68k-palmos/lib/libcrt.a(hooks.o)(.text+0x16):hooks.c: relocation > truncated to fit: DISP16 start > /usr/m68k-palmos/lib/libcrt.a(hooks.o)(.text+0x64):hooks.c: relocation > truncated to fit: DISP16 start > /usr/m68k-palmos/lib/libcrt.a(hooks.o)(.text+0xa6):hooks.c: relocation > truncated to fit: DISP16 start > /usr/m68k-palmos/lib/libcrt.a(hooks.o)(.text+0xe0):hooks.c: relocation > truncated to fit: DISP16 start > /usr/m68k-palmos/lib/libcrt.a(multi_dreloc.o)(.text+0xe):dreloc.c: > relocation truncated to fit: DISP16 start > collect2: ld returned 1 exit status > make: *** [myapp] Error 1 > All the references mentioned above are in the startup code which is at the beginning of the .text segment. The actual routines (GccRelocateData, etc.) are pulled in from libcrt.a which is at the end, after all your own object files. The distance from crt0.o to the library routines is larger than 32767 (signed 16-bit offset) hence the errormessages. So my guess is that you are just over the limit for the .text segment. Best thing to do is to move one or more routines to one of your other segments or to a new segment. (unless you want to force those routines from libcrt.a to somewhere in the middle of the .text segment ) Ton van Overbeek -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: multisegmenting troubles
Chris Faherty <[EMAIL PROTECTED]> wrote: > > On Tuesday 18 February 2003 05:50 pm, Rick Reynolds wrote: >> I've actually been in contact with both Ton van Overbeek (hacked gdb to >> work with multisegmented apps) and David Williams (author of multilink) >> about this. Apparently the script that multilink puts out isn't read >> correctly by the current gdb. > > Ah ok. That's the same issue. The fix is in the CVS: > > >http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/prc-tools/prc-tools/gdb-5.3.palmos.diff > > Various multiple code resources-related scripts use a convenience > variable as the load address for add-symbol-file. This hasn't > worked in GDB 5.x for a while because it allows only a constant > there.. > I had forgotten it was already fixed in prc-tools cvs. Thanks for the reminder. Time for prc-tools-2.3 ... ? Ton van Overbeek -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Newbie gdb and Palm OS 5 Simulator debugging question
Daryl Huff <[EMAIL PROTECTED]> wrote: > > I'm trying to debug my first Palm app using the PRC tools and I can't > get gdb (m68k-palmos-gdb) to connect to the Palm OS 5 Simulator to debug > my app. I carefully followed the instructions at > http://prc-tools.sourceforge.net/install/cygwin.html to install > everything onto my Win XP system. I have the SDK and PilRC on my system > and I can compile and run my app fine in the Simulator. I did build and > link with the -g flag set. > > However, when I go to connect the debugger to the simulator. I > > -start the simulator, > -double check the debugging port is set to "localhost:2000", > -load my app (Hello2 from PalmOS Programming Bible), > -start GDB with the name of the app "m68k-palmos-gdb hello2" > -type in "target pilot localhost:2000" > > and all the cygwin window does is print the following: > > Remote debugging under PalmOS using localhost:2000 > Waiting... (Press Ctrl-C to connect to halted machine) > > I run my app in the simulator and the gdb window never seems to connect. > If I close the simulator window the cygwin window immediatly reports: > > Couldn't establish connection to remote target > Remote communication error: Connection reset by peer. > > So I know it must have known about the Simulator window. > > I must be doing something basic incorrectly but for the life of me I > can't figure out what. Please help. > You also need the gdbpanel.prc installed on the simulator. Since you get the message: Remote debugging under PalmOS using localhost:2000 Waiting... (Press Ctrl-C to connect to halted machine) it means the TCP connection between POSE and the simulator has been established. gdbpanel can be found in the prc-tools-samples collection. See http://sourceforge.net/project/showfiles.php?group_id=4429. Before starting your app on the simulator, first launch gdbpanel, enable the gdbstub, return to the launcher and then launch the app you want to debug. What happens is that gdbpanel sets the 'gdbS' feature. The gdb startup code (when linked with -g) looks for this feature. If it is present it will break at PilotMain, if not the app will run normally. POSE sets this feature automatically, so you do not need gdbpanel when debugging with POSE. When you want to debug on a real device you will also need gdbpanel. See also http://www.falch.net/Articles?art=338 which addresses the same issue, but for running the sim and gdb together with the Falch IDE. Look at the last part of the article about gdbpanel. Ton van Overbeek -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
