[ECOS] What's the process on switching version control system for eCos?

[ECOS] What's the process on switching version control system for eCos?

[Øyvind Harboe]

eCos is run in an open manner.

Is there someone who's in charge of the process of switching to
a new distributed version control system?

Are we just throwing stuff around currently?

I'd like to see a renewed patch process in place as part
of the new version control system switch.

I guess the maintainers will have to make a choice on
behalf of the community, so there won't actually be a vote as
such. Since eCos is run in an open manner, this major
change should take the community's input and not
be presented as a fait accomplis though.

-- 
Øyvind Harboe
Embedded software and hardware consulting services
http://www.zylin.com

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

Re: [ECOS] What's the process on switching version control system for eCos?

[Alex Schuilenburg]

Øyvind Harboe wrote on 2009-09-21 10:50:
> eCos is run in an open manner.
>
> Is there someone who's in charge of the process of switching to
> a new distributed version control system?
>   
As far as I know, there is nobody, although the maintainers are
obviously aware that there is a public demand for a change.  This is not
the first time this has been raised.

I am aiming to put forward a proposal to the maintainers for a change,
along with recommendations, but ultimately the decision and process
rests with them.  I have also offered to do some of the legwork (e.g.
fix anoncvs and do the conversion).


> Are we just throwing stuff around currently?
>   
I hope it is more than just throwing stuff around.  I hope it is a fair
open discussion on the choices, pros, cons, etc for everyone to see.

I would certainly like to see a change, and believe the rest of the
community would also, and would expect the maintainers to respond
accordingly.  However, I have not had much of a chance to put together a
proposal to the maintainers, but will post here once it is done along
with links to the proposal.


> I'd like to see a renewed patch process in place as part
> of the new version control system switch.
>
> I guess the maintainers will have to make a choice on
> behalf of the community, so there won't actually be a vote as
> such. Since eCos is run in an open manner, this major
> change should take the community's input and not
> be presented as a fait accomplis though.
>   
Each of the three DRCS systems has a built-in method for submitting
patches upstream in a clean, well defined format. Otherwise they would
not be a proper DRCS IMHO ;-)   Hence I would expect that the choice of
DRCS would probably set the format. IMHO this would benefit the project
immensely because it simplifies the whole process of creating patches
for submission to the DRCS tool, making it easy for newcomers and the
like to create patches for contribution. To vary from this would kind-of
defeat one of the objectives of a DRCS.

I would however expect the submission process to be flexible (e.g.
email, attachments to bugzilla entries, etc), but again I expect the
maintainers should have the final say since it is them who will have to
review the patches before accepting and applying them.  I expect the
management of the submissions, since all major ones require assignments
and certain maintainers may be better skilled to review certain
contributions than others, to be one of the most important aspects to them.

-- Alex Schuilenburg

   >>>> Visit us at ESC-Boston  http://www.embedded.com/esc/boston <<<<
   >>>> Sep 22-23 on Stand 226  at Hynes Convention Center, Boston <<<<

       >>>> Visit us at ESC-UK  http://www.embedded.co.uk <<<<
       >>>> Oct 7-8 on Stand 433 at FIVE ISC, Farnborough <<<<


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

Re: [ECOS] What's the process on switching version control system for eCos?

[Bart Veer]

>>>>> "Oyvind" == =?UTF-8?Q?=C3=98yvind Harboe?= <oyvind.harboe@zylin.com> writes:

    Oyvind> eCos is run in an open manner.
    Oyvind> Is there someone who's in charge of the process of
    Oyvind> switching to a new distributed version control system?

Not at this time.    
    
    Oyvind> Are we just throwing stuff around currently?

Yes.

    Oyvind> I'd like to see a renewed patch process in place as part
    Oyvind> of the new version control system switch.

    Oyvind> I guess the maintainers will have to make a choice on
    Oyvind> behalf of the community, so there won't actually be a vote
    Oyvind> as such. Since eCos is run in an open manner, this major
    Oyvind> change should take the community's input and not be
    Oyvind> presented as a fait accomplis though.

The final decision will be made by the maintainers, although
there will have to be some consultation with the sourceware.org to
make sure that they are happy with the choice. Constructive input from
the community will be welcomed at the appropriate time.

However, at this time there is no formal proposal before the
maintainers, and so far none of the maintainers have volunteered to
work on a switch over. It seems likely that there will be at least
one, possibly more, proposals in the coming weeks or months. I would
expect any such proposal to address at least the following issues:

1) cvs is known to be broken in various ways, and sourceware.org has
run with various revisions of cvs with different bugs over the years.
Hence a full import of the current cvs repository into the proposed
system is likely to be problematical. More precisely, it probably
won't be too hard to get to a state where it is possible to check out
something equivalent to the current cvs trunk; however, replicating
the full history of the repository on all branches will be much more
difficult. So:

  a) how much effort will be contributed to minimize the loss of
     history?

  b) how much history can we expect to lose, irrespective of the
     amount of effort put in?

2) sorting out the repository itself is only part of the problem. The
web pages will need updating. There will almost certainly be teething
problems early on, e.g. the system may fail to work for some people
because of firewall issues. Can we expect any assistance with issues
like those?

So, a suggestion that e.g. eCos should switch over to git because it
is already in use on other projects is unlikely to get much attention
from the maintainers. A serious offer to do the hard work will get
much more attention, especially if it is backed up with experimental
data and explanations of why some of the problems with cvs are just
too hard to work around.

To a large extent, in this case the actual choice of which system to
switch to is less important than who will end up doing the work. The
three main distributed version control systems (mercurial, git, and
bazaar) all seem to offer much the same functionality, and all of them
are far superior to cvs. If pressed I would have to admit to a slight
preference for mercurial, partly because it has a reputation for being
easier to use than the others (especially in the context of Windows
users), and partly because it has rather good documentation in the
form of the O'Reilly book "Mercurial: the Definitive Guide".

Bart

-- 
Bart Veer                                   eCos Configuration Architect
eCosCentric Limited    The eCos experts      http://www.ecoscentric.com/
Barnwell House, Barnwell Drive, Cambridge, UK.      Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
 >>>> Visit us at ESC-Boston  http://www.embedded.com/esc/boston <<<<
 >>>> Sep 22-23 on Stand 226  at Hynes Convention Center, Boston <<<<

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

Re: [ECOS] What's the process on switching version control system for eCos?

[Øyvind Harboe]

>  b) how much history can we expect to lose, irrespective of the
>     amount of effort put in?

And c) given that the *entire* repository will be replicated to everybody
who wants to clone the eCos repository, how big do we really want
the repository to be?

the distributed source control systems allow the repository to be
downloaded as a single huge file, so even if the repository size is
in the hundreds of megabytes, it's not *too* bad if you are blessed
with fiber...

I haven't heard any guestimates on the expected git repository
size(I don't know of a significant difference in repository size
efficiency between the various systems).


-- 
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer

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

[ECOS] Re: What's the process on switching version control system for eCos?

[Sergei Organov]

Øyvind Harboe <oyvind.harboe@zylin.com> writes:

>>  b) how much history can we expect to lose, irrespective of the
>>     amount of effort put in?
>
> And c) given that the *entire* repository will be replicated to everybody
> who wants to clone the eCos repository, how big do we really want
> the repository to be?
>
> the distributed source control systems allow the repository to be
> downloaded as a single huge file, so even if the repository size is
> in the hundreds of megabytes, it's not *too* bad if you are blessed
> with fiber...
>
> I haven't heard any guestimates on the expected git repository
> size(I don't know of a significant difference in repository size
> efficiency between the various systems).

IMHO, eCos is not that big to worry about the size of the repository,
provided huge binary images are not put into the repository.

[But yes, git is very efficient at compressing of its data.]

-- Sergei.


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

Re: [ECOS] Re: What's the process on switching version control system for eCos?

[Alex Schuilenburg]

Sergei Organov wrote on 2009-09-22 15:59:
> Øyvind Harboe <oyvind.harboe@zylin.com> writes:
> [...]
> IMHO, eCos is not that big to worry about the size of the repository,
> provided huge binary images are not put into the repository.
>   
ROTFLMAO!!!

Seen ecos-images?!?!?

FAOD, I have begun the process of converting anoncvs to mercurial.  It
is not a raw "hg convert" since so far I have found 199 files which
confused CVS.  This was the time where CVS had the bug where files
introduced on a branch were automatically introduced into the trunk
instead.  An update of CVS later fixed this bug by marking these files
in the trunk as 1.1(dead).  I also have found various files which for
some reason were not tagged by CVS (have not a clue why, but at least
they were present when the releases were shipped).  The choice of files
CVS ommitted to tag appears completely random.

And yes, I have tried cvs2svn, git etc etc etc to make the conversion. 
The tool I have found that gets closest is a modified cvsps 2.2beta 1. 
I say modified because, unsurprisingly, some images (gif's, png's) are
erroneously not marked as binary within CVS so the patches generated by
cvsps or even diff are b0RkeD.

My choice of mercurial is immaterial as to the final choice of DRCS
since it can easily be exported to git or bzr if that is the final
chosen DRCS.

Also, I will be killing the images (some 98MB) from the repo, but will
preserve it as a separate repo in case anyone is insane enough to want
them.  FYI, they were various binary images of gdb stubs or redboot for
rom or ram or romram startup for various platforms, most of which are
now obsolete.  While a nice idea, the practice of keeping the images
updated for new platforms was not followed by the maintainers since we
left planet Red Hat.  You can always merge the repositories if you want
a closer reproduction of CVS. 

I say closer because, rather than doing a faithful CVS convertion, I am
fixing problems like files not actually being tagged as part of a
release (i.e cvs co -r <tag>) despite existing in the repo on a branch
when the tag was made and being shipped with the release and others
previously mentions.  I have had to become a CVS expert to detect and
fix most of these problems and now HATE CVS with such a passion you
would not believe.

I intend to make this hg repo available to everyone from one of our
servers, and will update it at least weekly with updates from anoncvs
(maybe daily, depends on the load) until a DRCS choice has been made and
is live on sourceware.  At least until then some folks have an
alternative download method and can better prepare
patchsets/contributions. Actual delivery date depends on my "real work"
workload.  Talking about which...

-- Alex Schuilenburg

   >>>> Visit us at ESC-Boston  http://www.embedded.com/esc/boston <<<<
   >>>> Sep 22-23 on Stand 226  at Hynes Convention Center, Boston <<<<

       >>>> Visit us at ESC-UK  http://www.embedded.co.uk <<<<
       >>>> Oct 7-8 on Stand 433 at FIVE ISC, Farnborough <<<<



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

[ECOS] Re: What's the process on switching version control system for eCos?

[Sergei Organov]

Alex Schuilenburg <alexs@ecoscentric.com> writes:
> Sergei Organov wrote on 2009-09-22 15:59:
>> Øyvind Harboe <oyvind.harboe@zylin.com> writes:
>> [...]
>> IMHO, eCos is not that big to worry about the size of the repository,
>> provided huge binary images are not put into the repository.
>>   
> ROTFLMAO!!!
>
> Seen ecos-images?!?!?

That's what I meant. They shouldn't be there in the eCos source code
repository, be it CVS or anything else. Someone who needs them (though I
doubt anybody does) should be able to download them separately.

[...]

> My choice of mercurial is immaterial as to the final choice of DRCS
> since it can easily be exported to git or bzr if that is the final
> chosen DRCS.

Yes, sure, so the tool that works best for conversion, or those one you
are most comfortable with is preferred.

> Also, I will be killing the images (some 98MB) from the repo, but will
> preserve it as a separate repo in case anyone is insane enough to want
> them.  FYI, they were various binary images of gdb stubs or redboot for
> rom or ram or romram startup for various platforms, most of which are
> now obsolete.  While a nice idea, the practice of keeping the images
> updated for new platforms was not followed by the maintainers since we
> left planet Red Hat.  You can always merge the repositories if you want
> a closer reproduction of CVS.

Yes, this is very reasonable decision.

> I say closer because, rather than doing a faithful CVS convertion, I am
> fixing problems like files not actually being tagged as part of a
> release (i.e cvs co -r <tag>) despite existing in the repo on a branch
> when the tag was made and being shipped with the release and others
> previously mentions.  I have had to become a CVS expert to detect and
> fix most of these problems and now HATE CVS with such a passion you
> would not believe.

I've tried to convert a few CVS repositories to git, so I do know what
you are talking about. You have my sympathies!

> I intend to make this hg repo available to everyone from one of our
> servers, and will update it at least weekly with updates from anoncvs
> (maybe daily, depends on the load) until a DRCS choice has been made and
> is live on sourceware.  At least until then some folks have an
> alternative download method and can better prepare
> patchsets/contributions. Actual delivery date depends on my "real work"
> workload.  Talking about which...

Oh, you even hope to have incremental updates! Very nice indeed!

-- Sergei.


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

Re: [ECOS] What's the process on switching version control system for eCos?

[Alex Schuilenburg]

Bart Veer wrote on 2009-09-22 15:34:
> [...]
> 1) cvs is known to be broken in various ways, and sourceware.org has
> run with various revisions of cvs with different bugs over the years.
> Hence a full import of the current cvs repository into the proposed
> system is likely to be problematical. More precisely, it probably
> won't be too hard to get to a state where it is possible to check out
> something equivalent to the current cvs trunk; however, replicating
> the full history of the repository on all branches will be much more
> difficult. So:
>
>   a) how much effort will be contributed to minimize the loss of
>      history?
>   
As I now have a perl script that uses cvsps and cvs to reconstruct every
checkin, as well as fix checkouts of "tagged" releases and files
missing/added to branches/trunk because of CVS bugs, I don't anticipate
history will be lost.  In fact I expect history to be gained because of
the fixes ;-)

>   b) how much history can we expect to lose, irrespective of the
>      amount of effort put in?
>   
Only what cvsps misses, or rather, does not know what to do with (google
CVSPS_NO_BRANCH for details). Those files or changes are basically
orphaned.  However, I will send a list of the files along with their
revisions to the maintainers and you can decide what to do with them.

> 2) sorting out the repository itself is only part of the problem. The
> web pages will need updating. There will almost certainly be teething
> problems early on, e.g. the system may fail to work for some people
> because of firewall issues. Can we expect any assistance with issues
> like those?
>
> So, a suggestion that e.g. eCos should switch over to git because it
> is already in use on other projects is unlikely to get much attention
> from the maintainers. A serious offer to do the hard work will get
> much more attention, especially if it is backed up with experimental
> data and explanations of why some of the problems with cvs are just
> too hard to work around.
>   
My offer in my previous email is serious.  Little skin off my nose and
most CPU cycles are free.  I have already developed my script in-house
for an internal conversion and so we can evaluate the different DRCS
systems.  What the maintainers or community choose to do with the repo
is up to them, but moving an hg repo to sourceware will be has hard as
"hg clone http://hg.ecoscentric.com/ecos", while converting it to git or
bzr a matter of exporting the patchsets (this time without error) from
hg after cloning it and importing them.

I guess I can summarise what problems were found within CVS during the
script's conversion, illustrating why "straight-forward" automated tools
like "hg convert" and other equivalents would not work.  It took all of
5 minutes to do a straight convertion with hg and a 30 second "diff -q
-r -x .hg -x .hgtags -x .cvsignore -x CVS <cvs-co> <hg-co>" to show that
a "straight-forward" conversion does not work.

-- Alex Schuilenburg

   >>>> Visit us at ESC-Boston  http://www.embedded.com/esc/boston <<<<
   >>>> Sep 22-23 on Stand 226  at Hynes Convention Center, Boston <<<<

       >>>> Visit us at ESC-UK  http://www.embedded.co.uk <<<<
       >>>> Oct 7-8 on Stand 433 at FIVE ISC, Farnborough <<<<


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

Re: [ECOS] Re: What's the process on switching version control system for eCos?

[Jonathan Larmour]

Sergei Organov wrote:
> Alex Schuilenburg <alexs@ecoscentric.com> writes:
> 
>>Sergei Organov wrote on 2009-09-22 15:59:
>>
>>>Øyvind Harboe <oyvind.harboe@zylin.com> writes:
>>>[...]
>>>IMHO, eCos is not that big to worry about the size of the repository,
>>>provided huge binary images are not put into the repository.
>>>  
>>
>>ROTFLMAO!!!
>>
>>Seen ecos-images?!?!?
> 
> 
> That's what I meant. They shouldn't be there in the eCos source code
> repository, be it CVS or anything else. Someone who needs them (though I
> doubt anybody does) should be able to download them separately.

Given their original raison d'etre it made sense at the time - known good 
images appropriate (more or less) to the source code at a particular date, 
and put under version control.

But they have not been kept up-to-date, and the ones there are pretty much 
all for obsolete platforms. I would have no objections for a new DRCS 
leaving them out. We will always have the original CVS sitting around for 
archaeology, although I'd doubt we'd ever touch them!

Even if someone was willing to (somehow) make a new set of known-good 
images for current platforms, that should live in a separate repo, 
precisely to allow DRCS's to function sensibly.

>>I say closer because, rather than doing a faithful CVS convertion, I am
>>fixing problems like files not actually being tagged as part of a
>>release (i.e cvs co -r <tag>) despite existing in the repo on a branch
>>when the tag was made and being shipped with the release and others
>>previously mentions.  I have had to become a CVS expert to detect and
>>fix most of these problems and now HATE CVS with such a passion you
>>would not believe.
> 
> 
> I've tried to convert a few CVS repositories to git, so I do know what
> you are talking about. You have my sympathies!

I think the eCos repository has more challenges than usual due to various 
tricks played with over the years. I'll be glad to see the back of the 
ecos-net modules hack.

Jifl
-- 
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine

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

Re: [ECOS] What's the process on switching version control system for eCos?

[Jonathan Larmour]

Alex Schuilenburg wrote:
> Bart Veer wrote on 2009-09-22 15:34:
>>  b) how much history can we expect to lose, irrespective of the
>>     amount of effort put in?
>>  
> 
> Only what cvsps misses, or rather, does not know what to do with (google
> CVSPS_NO_BRANCH for details). Those files or changes are basically
> orphaned.  However, I will send a list of the files along with their
> revisions to the maintainers and you can decide what to do with them.

Frankly I wouldn't worry about it to that level - if that level of digging 
is required to find out past history, the best thing to do is to look 
directly at the old CVS repository.

Those orphaned changes are probably the result of "cvs admin" hacks and so 
on. In which case they were probably orphaned for a reason.

>>So, a suggestion that e.g. eCos should switch over to git because it
>>is already in use on other projects is unlikely to get much attention
>>from the maintainers. A serious offer to do the hard work will get
>>much more attention, especially if it is backed up with experimental
>>data and explanations of why some of the problems with cvs are just
>>too hard to work around.
>>  
> 
> My offer in my previous email is serious.  Little skin off my nose and
> most CPU cycles are free.  I have already developed my script in-house
> for an internal conversion and so we can evaluate the different DRCS
> systems.  What the maintainers or community choose to do with the repo
> is up to them, but moving an hg repo to sourceware will be has hard as
> "hg clone http://hg.ecoscentric.com/ecos", while converting it to git or
> bzr a matter of exporting the patchsets (this time without error) from
> hg after cloning it and importing them.

I for one would like to take you up on that! Even if the choice isn't hg 
that effort would be useful and not wasted.

Jifl
-- 
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine

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

[ECOS] Re: What's the process on switching version control system for eCos?

[Sergei Organov]

Jonathan Larmour <jifl@jifvik.org> writes:
> Sergei Organov wrote:

[...]

>> I've tried to convert a few CVS repositories to git, so I do know what
>> you are talking about. You have my sympathies!
>
> I think the eCos repository has more challenges than usual due to
> various tricks played with over the years.

Yeah, I know, I've tried to convert the eCos one as well ;-)

-- Sergei.


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

[ECOS] Help required for LDI file

[Himanshu Patel]

Hi, 

We are using LPC2458, which has scatter (non-continuous) SRAM memory. Now we want to assign bss section to this scatter memory. We tried to create sections as below but the same is giving linking error.
SECTION_bss (sram, 0x40000540, LMA_EQ_VMA)  
SECTION_bss (sram3, 0x7FD00a00, LMA_EQ_VMA)

How can we do that? What is the reason for error? 

Complete ldi file:

MEMORY
{
    rom    : ORIGIN = 0x00000000, LENGTH = 0x80000
    sram   : ORIGIN = 0x40000000, LENGTH = 0xFDE0
    sram2   : ORIGIN = 0x7FE00000, LENGTH = 0x4000
    sram3   : ORIGIN = 0x7FD00a00, LENGTH = 0x3600
}

SECTIONS
{
    SECTIONS_BEGIN
    SECTION_rom_vectors (rom, 0x00000000, LMA_EQ_VMA)
    SECTION_text (rom, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_fini (rom, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_rodata (rom, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_rodata1 (rom, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_fixup (rom, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_gcc_except_table (rom, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_fixed_vectors (sram, 0x40000400, LMA_EQ_VMA)
    SECTION_data (sram2, 0x7FE00000, FOLLOWING (.gcc_except_table))
    SECTION_bss (sram, 0x40000540, LMA_EQ_VMA)
    SECTION_bss (sram3, 0x7FD00a00, LMA_EQ_VMA)
    CYG_LABEL_DEFN(__heap1) = 0x7FD03200;
    SECTIONS_END
}

Regards,

Himanshu Patel



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

[ECOS] Re: Help required for LDI file

[John Dallaway]

Hi Himanshu

Himanshu Patel wrote:

> We are using LPC2458, which has scatter (non-continuous) SRAM memory. Now
> we want to assign bss section to this scatter memory. We tried to create
> sections as below but the same is giving linking error.
> SECTION_bss (sram, 0x40000540, LMA_EQ_VMA)  
> SECTION_bss (sram3, 0x7FD00a00, LMA_EQ_VMA)

The above code will attempt to define two linker output sections both
named ".bss". The GNU linker cannot allocate memory for symbols across
multiple memory regions in this way.

In order to split code or data across multiple memory regions, you will
need to define new output section macros (similar to those in arm.ld)
which are then mapped to the various memory regions by extending your
.ldi file. You must then adjust these macros to share the various
compiler-generated objects across the multiple output sections.

In the case of .bss, this is complicated by use of the __bss_start and
__bss_end symbols within eCos code. For example, there is code to zero
the bss at startup which assumes that the bss is contiguous. You will
need to examine how these symbols are used and accommodate any
assumptions that have been made.

I hope this helps

John Dallaway

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