On Tue, 18 Jan 2000, John Marshall wrote:
> You did remember to link with the `-g' flag didn't you? (As usual you
> need to compile with `-g' to get symbol information, but on Palm OS you
> also need to *link* with `-g' to get a debugger stub which gives you this
> initial breakpoint.)
>
Stupid mistake on my part! I don't know how I forgot that in the Makefile {8-|
> > Now to my question: Does prc-tools-0.5.1b3, specifically, GDB, suffer
> > from the same limitation as Multilink, in that you cannot debug
> > multiple code-resource applications? Have you, John, managed to
> > run TLP through the GDB debugger?
>
> That's an interesting question... I don't use debuggers much myself so I
> never thought to try that! The answer is yes, `m68k-palmos-gdb multiapp'
> does hit that first breakpoint and I can step through and set breakpoints
> in the main code resource. On a cursory examination, setting breakpoints
> in other code resources doesn't seem to work, and quite likely other
> symbolic information pointing at other code resources won't work either
> (hmmmm, there's something to investigate...).
>
Yes it seems, the same symptoms are exhibited in my testing of both TLP
and 2CViaggio, my application, bummer...
IAC, I have another question: when we talk about the ability of
Prc-tools-0.5.1 to support *multiple* code-resources, does that mean
*multiple* or just two (main, and an alternate)? Ok, I'll
confess, I tried to add another section to TLP, Pertinent Code:
----------- 8< --------------
void h() __attribute__ ((section ("andy")));
void h()
{
WinDrawChars ("I am h in andy!", 15, 10, 140);
}
void g()
{
WinDrawChars ("I am g in main code!", 20, 10, 100);
h();
}
void f() __attribute__ ((section ("bob")));
void f()
{
WinDrawChars ("I am f in bob!", 14, 10, 60);
g();
}
...
----------- 8< --------------
Then appended an appropriate line to the .def file:
multiple code { "andy" }
Make'd, installed the PRC POSE, ran the application. But,
POSE complained about:
'MultiApp' (unknown version) has just performed an illegal
operation. It performed a "TRAP instruction". If this is the
latest version of 'MultiApp', please report this to the applicatio
author.
Any hint as to what the problem is? Is it my declaration of section
'andy'? A multigen (.def file) problem? I usually code/compile/debug
within Xemacs, but since I can't debug an alternate code resource, I
cannot see where it is failing. I even tried to use DDD to
debug so that I could see the assembly code and trace instruction by
instruction, but of course I couldn't visually trace beyond the main code
resource. Hell, I even tried to compare the resultant assembly code
(generated with -S given to gcc) of the multiapp.c file with the number
of 'stepi' instructions it would take to generate the error once
I fell into the 'dark' (bob) code resource. That was certainly fun,
considering my last assembly language tour was eight to ten years
ago writing TSRs and stuff on the x86.
John, I realize this is certainly not a showstopper for prc-tools 0.5.1,
and in all honesty, I personally don't forsee my application using more
than two code resources, including main, instead maybe this small
report can go on your low-priority list of to-dos.
Thanks again for all your work on prc-tools...
andy
