[ECOS] Re: A build and a debug question

[ECOS] Re: A build and a debug question

[Gary D. Thomas]

On Tue, 2003-03-25 at 07:29, Westwood, Geoff wrote:
> Hello Both
> 
> Thanks for taking the time to help with my gdb problem
> 

Sorry, but private help is only available on contract.  Email sent
directly to me in the future that is not copied to the list will
be quietly ignored. I am copying this to the list so that everyone 
can benefit from this free service.If you want private support, 
contact me.

> I am at work now so I had chance to test this again
> 
> I am using the Viper PowerPC 855T board, Building using  Cygwin on Win NT
> and the Gui config tool
> 

What Viper 855T? - the Viper from Analogue & Micro is an 860T
(not that it makes much difference at this point)

> I started again this morning by clearing my build directory and rebuilding
> the library for the Viper default build.
> I then built the Viper hello.c test. This builds OK, and downloads using
> gdb, and runs fine cycles leds and outputs text to the gdb console
> 
> I then deleted the build dir contents for tidiness and just changed the
> default package to "new_net" package and built again. This built ok , note I
> did get a window asking about resolving conflicts, I just clicked on
> continue in this window. This builds and I can compile and link the hello.c
> program.
> however when I  use gdb ( powerpc-eabi-gdb -nw hello.exe) and after typing
> target remote 10.20.111.111:9000 I get the error
> 
> (gdb) target remote 10.20.111.111:9000
> Remote debugging using 10.20.111.111:9000
> gdb-internal-error: longest_local_hex_string_custom: insufficient space to
> store result
> 

What happens if you try to connect via the serial port?
Have you tried turning on GDB debugging (set remotedebug 1)?  This will
show something of what's going on.

If it works with one configurstion and not another, what's the 
difference between them?  In this case, the executable will be somewhat
larger, but much less than the available memory size.

> I am using the ecos snapshot   "ecos-v2-full-beta-snap-2003-03-10.tar.bz2",
> I unzipped this onto a network drive and pointed the config tool at this
> repository.
> 
> I am sure this fault is triggered just by me selecting "new_net" and it is
> 100% repeatable for me. I did wonder if I should be using "net" instead of
> "new_net"
> I tried to build with "net"  but eCos wouldn't build, so I concluded I was
> correct first time in using "new_net"

From the snapshot you are using, both network stacks built fine.  What
problem did you encounter?

> 
> Not sure what else I can tell you regarding my setup ? Thanks for any
> thoughts you might have on this problem
> 
> 	Regards Geoff Westwood
> 
-- 
.--------------------------------------------------------.
|       Mind: Embedded Linux and eCos Development        |
|--------------------------------------------------------|
| Gary Thomas              email:  gary.thomas@mind.be   |
| Mind ( http://mind.be )  tel:    +1 (970) 229-1963     |
| gpg: http://www.chez-thomas.org/gary/gpg_key.asc       |
'--------------------------------------------------------'


-- 
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] RE: A build and a debug question

[Jonathan Larmour]

>>	A prebuilt one. The startup banner is "GNU gdb 5.0-gnupro-00r1"

Ah. I strongly recommend switching to 5.3 since that's what we're using, 
and we know it works. You can get prebuilts by using the ecos 2.0beta 
installer

>>	> (gdb) target remote 10.20.111.111:9000
>>	> Remote debugging using 10.20.111.111:9000
>>	> gdb-internal-error: longest_local_hex_string_custom: insufficient
>>space to
>>	> store result
>>
>>	The fact it happens with new_net implies it's something to do with
>>the 
>>	RedBoot/eCos sharing. Have you given the target its own address? You
>>can't 
>>	allocate both redboot and ecos addresses dynamically.
>>
>>	This sounds a likely cause. I hadn't given the IP address issue much
>>thought or investigation at this stage . I had used Redboot to program an
>>appropriate IP address and subnet mask. I had kind of assumed any network
>>App will look in the same Flash area and by default use the IP params I had
>>set via Redboot. Maybe this isn't the way it works, I will go and try and
>>find some explanation on this in the docs.
> 
> 
> I truly doubt that this is the issue, since the problem 
> occurs during the initial connection.  The eCos application
> is not even started running yet, much less competing for
> IP addresses.

True - somehow it slipped my mind when it came to me it was at the target 
remote stage so it couldn't possibly be that.

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- 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

Re: [ECOS] RE: A build and a debug question

[Gary D. Thomas]

On Wed, 2003-03-26 at 02:58, Westwood, Geoff wrote:
> 	Hi 
> 
> 	I would slightly prefer it if this was kept on the list. "Private" 
> 	one-to-one support, for eCosCentric is something we charge for, but
> we do 
> 	try and help people to a limited extent on the lists. But on the
> proviso 
> 	that the discussion is kept there so everyone gets the (potential!) 
> 	benefit of the resolution.
> 
> 	Sorry about that. I was having trouble posting to the list from my
> work PC. I figured out what the problem was now
> 	(It doesn't like the html mime option being on)
> 
> 	>This your own GDB or the prebuilt one?
> 
> 	A prebuilt one. The startup banner is "GNU gdb 5.0-gnupro-00r1"
> 
> 	> (gdb) target remote 10.20.111.111:9000
> 	> Remote debugging using 10.20.111.111:9000
> 	> gdb-internal-error: longest_local_hex_string_custom: insufficient
> space to
> 	> store result
> 
> 	The fact it happens with new_net implies it's something to do with
> the 
> 	RedBoot/eCos sharing. Have you given the target its own address? You
> can't 
> 	allocate both redboot and ecos addresses dynamically.
> 
> 	This sounds a likely cause. I hadn't given the IP address issue much
> thought or investigation at this stage . I had used Redboot to program an
> appropriate IP address and subnet mask. I had kind of assumed any network
> App will look in the same Flash area and by default use the IP params I had
> set via Redboot. Maybe this isn't the way it works, I will go and try and
> find some explanation on this in the docs.

I truly doubt that this is the issue, since the problem 
occurs during the initial connection.  The eCos application
is not even started running yet, much less competing for
IP addresses.

-- 
.--------------------------------------------------------.
|       Mind: Embedded Linux and eCos Development        |
|--------------------------------------------------------|
| Gary Thomas              email:  gary.thomas@mind.be   |
| Mind ( http://mind.be )  tel:    +1 (970) 229-1963     |
| gpg: http://www.chez-thomas.org/gary/gpg_key.asc       |
'--------------------------------------------------------'


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

[ECOS] RE: A build and a debug question

[Westwood, Geoff]

	Hi 

	I would slightly prefer it if this was kept on the list. "Private" 
	one-to-one support, for eCosCentric is something we charge for, but
we do 
	try and help people to a limited extent on the lists. But on the
proviso 
	that the discussion is kept there so everyone gets the (potential!) 
	benefit of the resolution.

	Sorry about that. I was having trouble posting to the list from my
work PC. I figured out what the problem was now
	(It doesn't like the html mime option being on)

	>This your own GDB or the prebuilt one?

	A prebuilt one. The startup banner is "GNU gdb 5.0-gnupro-00r1"

	> (gdb) target remote 10.20.111.111:9000
	> Remote debugging using 10.20.111.111:9000
	> gdb-internal-error: longest_local_hex_string_custom: insufficient
space to
	> store result

	The fact it happens with new_net implies it's something to do with
the 
	RedBoot/eCos sharing. Have you given the target its own address? You
can't 
	allocate both redboot and ecos addresses dynamically.

	This sounds a likely cause. I hadn't given the IP address issue much
thought or investigation at this stage . I had used Redboot to program an
appropriate IP address and subnet mask. I had kind of assumed any network
App will look in the same Flash area and by default use the IP params I had
set via Redboot. Maybe this isn't the way it works, I will go and try and
find some explanation on this in the docs.

			Regards Geoff

-- 
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] Re: A Build and a debug question

[Jonathan Larmour]

Geoff wrote:
> 
> Q1)
> Re: the build warnings. They were mainly associated with the network stack
> files. I was just trying to ascertain if some warnings were to be expected.
> I thought it might be indicative that I had done something wrong in the OS
> build and hence might be related to my gdb problem

Nah, don't worry. A lot of the warnings from both the networking stack and 
the SNMP stack are because they are sources imported from elsewhere. While 
100% warning cleanliness is a good goal in general, it's also inadvisable 
to perturb imported sources too much for the sake of future merges.

> Q2)
> Sorry for my unfamiliarity with this but I had not even spotted a section in
> the config tool for specifyng start up options. I think the gdb error
> appeared when I switched from the default package (no network stack) to the
> new_net package. Hopefully I am using a Ram Only start-up type on the Viper
> board. I have had a quick search through the docs but cant find much on
> start-up options.

This may be a silly suggestion, but given what the warning actually said, 
are you sure you are running "powerpc-eabi-gdb" and not just "gdb"?

Otherwise, it certainly implies some problem with the remote protocol 
(which is based on hex strings). Is it repeatable? As Gary suggests, 
trying the eCos tests would be a good idea as it reduces the possibility 
of problems with building the executables.

If you still have no joy you should let us know a) how you built your 
application (compile and link line etc.) and b) how you are running GDB 
(command line and commands).

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- 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

Re: [ECOS] Re: A Build and a debug question

[Gary D. Thomas]

On Mon, 2003-03-24 at 15:12, Geoff wrote:
> Hi Gary
> 
> Q1)
> Re: the build warnings. They were mainly associated with the network stack
> files. I was just trying to ascertain if some warnings were to be expected.
> I thought it might be indicative that I had done something wrong in the OS
> build and hence might be related to my gdb problem
> 
> 
> Q2)
> Sorry for my unfamiliarity with this but I had not even spotted a section in
> the config tool for specifyng start up options. I think the gdb error
> appeared when I switched from the default package (no network stack) to the
> new_net package. Hopefully I am using a Ram Only start-up type on the Viper
> board. I have had a quick search through the docs but cant find much on
> start-up options.

The default startup type is RAM, which is what you mostly want.

Have you tried to build & run the standard tests?  This is a
good first step, to get used to the tools and also to verify
your installation.  Something as simple as:
  % ecosconfig new viper net
  % ecosconfig tree
  % make; make tests
Then try to run the tests found in "install/tests/..."

You could also look at some of the simple "hello world" examples.
These are in the examples directory, and there is good documentation
about how to build them.

Finally, you can try the [somewhat more ambitious] examples that
I've put together.  Look at:
  http://www.mlbassoc.com/examples/

-- 
.--------------------------------------------------------.
|       Mind: Embedded Linux and eCos Development        |
|--------------------------------------------------------|
| Gary Thomas              email:  gary.thomas@mind.be   |
| Mind ( http://mind.be )  tel:    +1 (970) 229-1963     |
| gpg: http://www.chez-thomas.org/gary/gpg_key.asc       |
'--------------------------------------------------------'


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

[ECOS] Re: A Build and a debug question

[Geoff]

Hi Gary

Q1)
Re: the build warnings. They were mainly associated with the network stack
files. I was just trying to ascertain if some warnings were to be expected.
I thought it might be indicative that I had done something wrong in the OS
build and hence might be related to my gdb problem


Q2)
Sorry for my unfamiliarity with this but I had not even spotted a section in
the config tool for specifyng start up options. I think the gdb error
appeared when I switched from the default package (no network stack) to the
new_net package. Hopefully I am using a Ram Only start-up type on the Viper
board. I have had a quick search through the docs but cant find much on
start-up options.

        Geoff




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