[ECOS] Turn off gdb console?

[ECOS] Turn off gdb console?

[bgat]

Hi!  Quick question...


I'm trying to run the test applications in the latest eCos CVS
repository, like dhrystone, over ethernet using RedBoot on the MBX.
As expected, whenever there's a printf() in dhrystone, it shows up on
the serial port, formatted as a gdb "console output" message.

This behavior would make sense if I was talking to the MBX target over
the serial port, but I'm not.  Furthermore, what I would like to see
is raw, streaming output from dhrystone on the serial port; I want to
control the application via ethernet, but not have the console tied to
gdb's console.

I gave my ecos.ecc file a quick skim, and didn't come across anything
that was obviously related to console output formatting.  What's the
CYG_xxx that I use?


Thanks!


b.g.
-- 
Bill Gatliff
bgat@open-widgets.com

Re: [ECOS] Turn off gdb console?

[Jonathan Larmour]

bgat@open-widgets.com wrote:
> 
> Hi!  Quick question...
> 
> I'm trying to run the test applications in the latest eCos CVS
> repository, like dhrystone, over ethernet using RedBoot on the MBX.
> As expected, whenever there's a printf() in dhrystone, it shows up on
> the serial port, formatted as a gdb "console output" message.
> 
> This behavior would make sense if I was talking to the MBX target over
> the serial port, but I'm not.  Furthermore, what I would like to see
> is raw, streaming output from dhrystone on the serial port; I want to
> control the application via ethernet, but not have the console tied to
> gdb's console.
> 
> I gave my ecos.ecc file a quick skim, and didn't come across anything
> that was obviously related to console output formatting.  What's the
> CYG_xxx that I use?

Believe it or not, we're just working on a generic solution to this type of
situation that will allow a loaded application to claim the
console/debugging virtual vectors

But for now I believe you should be able to enable the option
CYGDBG_HAL_DIAG_DISABLE_GDB_PROTOCOL, which should turn off GDB packet
encoding in the MBX hal diag output (assuming you have not explicitly
enabled virtual vector diag).

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

Re: [ECOS] Turn off gdb console?

[bgat]

Jifl:


That's EXACTLY what I was looking for, for now.  Thanks!


b.g.




On Wed, Jan 31, 2001 at 03:07:23AM +0000, Jonathan Larmour wrote:
> bgat@open-widgets.com wrote:
> > 
> > Hi!  Quick question...
> > 
> > I'm trying to run the test applications in the latest eCos CVS
> > repository, like dhrystone, over ethernet using RedBoot on the MBX.
> > As expected, whenever there's a printf() in dhrystone, it shows up on
> > the serial port, formatted as a gdb "console output" message.
> > 
> > This behavior would make sense if I was talking to the MBX target over
> > the serial port, but I'm not.  Furthermore, what I would like to see
> > is raw, streaming output from dhrystone on the serial port; I want to
> > control the application via ethernet, but not have the console tied to
> > gdb's console.
> > 
> > I gave my ecos.ecc file a quick skim, and didn't come across anything
> > that was obviously related to console output formatting.  What's the
> > CYG_xxx that I use?
> 
> Believe it or not, we're just working on a generic solution to this type of
> situation that will allow a loaded application to claim the
> console/debugging virtual vectors
> 
> But for now I believe you should be able to enable the option
> CYGDBG_HAL_DIAG_DISABLE_GDB_PROTOCOL, which should turn off GDB packet
> encoding in the MBX hal diag output (assuming you have not explicitly
> enabled virtual vector diag).
> 
> Jifl
> -- 
> Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
> Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine
> 

-- 
Bill Gatliff
bgat@open-widgets.com

[ECOS] GDB stubs build problem for vrc4373

[Ling Su]

One problme bothers me is, I have never succeeded in building a GDB stub for
vrc4373 by using a CVS version snapshot. Actually only the binary version
provided in eCos 1.3.1 release works for me, whenver I tried to build a new
one by using the CVS version or any snapshot of source code, I just got a
dead monitor without any response. Basically I did "ecosconfig new vrc4373
stubs" and then make it. I was really puzzled me whether the CVS version (or
the Open Sourced version) really the same as what RedHat playing with. Or we
really need to buy a comercialzed GNUPro toolchain to make the compiled code
working. I can compile my code starting up in RAM and debug it using the
binary GDB stub provided in eCos1.3.1 release,  but why I can not make a
working GDB stub by myself? Anything I missed?

As you may know, I am trying to port the vrc4373 code to vrc4375 board, the
most important thing is to get a running stub, I want to make sure I can
build a working gdb stub for vrc4373 before I can change it to working on
vrc4375 board. I have been trying this for several days, no outcome. Any
advices? Thanks, and help, please... :-/


Regards,
-Ling