[ECOS] About "File I/O operations via GDB"

[ECOS] About "File I/O operations via GDB"

[Vincent Leclaire]

Hi everybody,

Does anyone have experience with this option ? My goal is to try to
route "fopens" (and the like) executed on the target to the debugging
host filesystem, presumably using GDB.

(target is an i386 pc but will change in the future, that's why I try to
simulate without using a disk!)

I've searched the lists. I've searched the Net. Nothing clear about
this, especially on non-ARM targets. Here's a snapshot of my knowledge
:-)

* I understand it's about Redboot syscalls and virtual vectors. Apart
from selecting the option what is needed ? I think I don't have problems
w/ virtual vectors since the "rest" seems to work. How can I make sure
my app is able to talk to Redboot if needed ?

* I guess the app (or the stdiolib) must be recompiled to map file i/o
operations, but I was unable to find info about the way to do it (on my
"i386-all" setup I cannot select the "file operations via GDB"
checkbox).

* The comment for the option says "doable only through RedBoot syscall".
Does it mean it must be hard-coded in the program by hand ? How do you
call those services (I know there are SYSCALL macros for this) ?

* Any special stuff for ARM targets (what is newlib / libgloss BTW) ?

* What about gdb/Insight special configuration on the debugging host ?

Thanks for any pointers you can provide !

Have a nice day

VL

--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] About "File I/O operations via GDB"

[Nick Garnett]

"Vincent Leclaire" <vleclaire@awox.com> writes:

> Hi everybody,
> 
> Does anyone have experience with this option ? My goal is to try to
> route "fopens" (and the like) executed on the target to the debugging
> host filesystem, presumably using GDB.
> 
> (target is an i386 pc but will change in the future, that's why I try to
> simulate without using a disk!)
> 
> I've searched the lists. I've searched the Net. Nothing clear about
> this, especially on non-ARM targets. Here's a snapshot of my knowledge
> :-)
> 
> * I understand it's about Redboot syscalls and virtual vectors. Apart
> from selecting the option what is needed ? I think I don't have problems
> w/ virtual vectors since the "rest" seems to work. How can I make sure
> my app is able to talk to Redboot if needed ?
> 
> * I guess the app (or the stdiolib) must be recompiled to map file i/o
> operations, but I was unable to find info about the way to do it (on my
> "i386-all" setup I cannot select the "file operations via GDB"
> checkbox).
> 
> * The comment for the option says "doable only through RedBoot syscall".
> Does it mean it must be hard-coded in the program by hand ? How do you
> call those services (I know there are SYSCALL macros for this) ?
> 
> * Any special stuff for ARM targets (what is newlib / libgloss BTW) ?
> 
> * What about gdb/Insight special configuration on the debugging host ?
> 
> Thanks for any pointers you can provide !

These operations are there to support stand-alone applications built
using just the gcc toolchain. They cannot be used from eCos.

The GCC toolchain contains its own stand-alone C library, called
newlib, which ultimately executes trap or syscall instructions to
handle any IO. RedBoot contains support to handle these and pass them
back to GDB. For this to work the appropriate support needs to be
included in GDB, which is not the default for most targets.


-- 
Nick Garnett                    eCos Kernel Architect
http://www.ecoscentric.com      The eCos and RedBoot experts


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] About "File I/O operations via GDB"

[Jonathan Larmour]

Nick Garnett wrote:
> "Vincent Leclaire" <vleclaire@awox.com> writes:
>>
>>Does anyone have experience with this option ? My goal is to try to
>>route "fopens" (and the like) executed on the target to the debugging
>>host filesystem, presumably using GDB.
>>
>>Thanks for any pointers you can provide !
> 
> 
> These operations are there to support stand-alone applications built
> using just the gcc toolchain. They cannot be used from eCos.

Yet ;-). But it would require work: creating a plugin filesystem using the 
fileio package that called into redboot would be the way to do it 
(different from normal FS's as it would dramatically affect real-time 
response, but that's just the price to pay). I doubt anyone's working on 
this, so it's up to you (Vincent) if you'd want it.

> The GCC toolchain contains its own stand-alone C library, called
> newlib, which ultimately executes trap or syscall instructions to
> handle any IO. RedBoot contains support to handle these and pass them
> back to GDB. For this to work the appropriate support needs to be
> included in GDB, which is not the default for most targets.

Specifically, only ARM at present. And you have to have linked your newlib 
app with the appropriate redboot.specs file.

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss