Re: Large patch to merge in changes for gcc 4.3

Re: Large patch to merge in changes for gcc 4.3

[Bart Veer]

Taking this ecos-devel.

>>>>> "Simon" == simon kallweit@intefo ch <simon.kallweit@intefo.ch> writes:

    Simon> Do you know if this patch also fixes debugging synth
    Simon> binaries with gdb 6.8 on Debian/Ubuntu, which were compiled
    Simon> with a new 4.x toolchain? I currently moved back to a
    Simon> legacy gcc (3.2.1) for synth debugging, which of course is
    Simon> very sub-optimal. I will get my own repo up to date once
    Simon> you also merged flash v2, so I can test again.

As far as I am aware nobody is working on this.

I believe there are two issues re. Debian/Ubuntu:

1) their builds of gcc default to -fstack-protector, whereas other
distributions default to -fno-stack-protection. Supporting that option
requires extra work inside the synthetic target, including
manipulating segment registers, and the details are not well
understood. For example it is not clear whether that extra work would
need to be done only during initialization or for every context switch
(the synthetic target does not support a separate interrupt stack so
that at least is not a concern).

  Ideally somebody would investigate this further and provide a suitable
patch for the synthetic target. I am not planning to work on this.

  A workaround would be to add -fno-stack-protector to the default
build flags for the synthetic target, but that would break builds for
older distributions which don't recognise the flag. So we have a
choice: fix this problem for current Debian/Ubuntu users while
breaking things for people with old distributions (they would have to
edit the relevant config option to remove the flag); or keep things
working for people with old distributions while breaking things for
Debian/Ubuntu users. I have no strong feelings either way. It has been
quite some time since the problem was first noticed so there should be
a lot fewer people with older distributions.

2) some Debian/Ubuntu builds of gdb report an internal error, as per
http://sourceware.org/ml/ecos-discuss/2008-09/msg00045.html

  This is not a bug in eCos, it is an internal error in gdb, although
it might be possible to avoid triggering the internal error by some
tweaking of the eCos code. As far as I know other Linux distributions
are not affected, and in particular I have not had any gdb problems
with the synthetic target under Fedora. So either:

  a) the Debian/Ubuntu builds of gdb incorporate a dodgy patch, or
  b) mainline gdb is broken, but Fedora and other distributions
     incorporate a patch that fixes the problem.

  So looking at the source packages for each distribution could help.
Actually figuring out exactly what in eCos causes the internal error
would also help. Either way this should really be fixed in the
Debian/Ubuntu world, not inside eCos. If somebody investigates further
and provides a harmless patch to the synthetic target which bypasses
the problem, that would be acceptable as well - but note the
"harmless".

  Again I am not currently planning to work on this. Some
Debian/Ubuntu user needs to step up to the plate.

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.

Re: Large patch to merge in changes for gcc 4.3

[Simon Kallweit]

Bart Veer wrote:
> Taking this ecos-devel.
>
>   
>>>>>> "Simon" == simon kallweit@intefo ch <simon.kallweit@intefo.ch> writes:
>>>>>>             
>
>     Simon> Do you know if this patch also fixes debugging synth
>     Simon> binaries with gdb 6.8 on Debian/Ubuntu, which were compiled
>     Simon> with a new 4.x toolchain? I currently moved back to a
>     Simon> legacy gcc (3.2.1) for synth debugging, which of course is
>     Simon> very sub-optimal. I will get my own repo up to date once
>     Simon> you also merged flash v2, so I can test again.
>
> As far as I am aware nobody is working on this.
>
> I believe there are two issues re. Debian/Ubuntu:
>
> 1) their builds of gcc default to -fstack-protector, whereas other
> distributions default to -fno-stack-protection. Supporting that option
> requires extra work inside the synthetic target, including
> manipulating segment registers, and the details are not well
> understood. For example it is not clear whether that extra work would
> need to be done only during initialization or for every context switch
> (the synthetic target does not support a separate interrupt stack so
> that at least is not a concern).
>
>   Ideally somebody would investigate this further and provide a suitable
> patch for the synthetic target. I am not planning to work on this.
>
>   A workaround would be to add -fno-stack-protector to the default
> build flags for the synthetic target, but that would break builds for
> older distributions which don't recognise the flag. So we have a
> choice: fix this problem for current Debian/Ubuntu users while
> breaking things for people with old distributions (they would have to
> edit the relevant config option to remove the flag); or keep things
> working for people with old distributions while breaking things for
> Debian/Ubuntu users. I have no strong feelings either way. It has been
> quite some time since the problem was first noticed so there should be
> a lot fewer people with older distributions.
>   

There was a little discussion a while ago about supporting the stack 
protector in eCos, but the idea was abandoned as it seemed to not be 
worth the effort. It's OK for me to change the CFLAGS as I'm the one 
using a "non-standard" toolchain enabling the stack protector by 
default. It might be worth mentioning in the documentation though, is 
there a suitable place, so to spare new users some hassle?
> 2) some Debian/Ubuntu builds of gdb report an internal error, as per
> http://sourceware.org/ml/ecos-discuss/2008-09/msg00045.html
>
>   This is not a bug in eCos, it is an internal error in gdb, although
> it might be possible to avoid triggering the internal error by some
> tweaking of the eCos code. As far as I know other Linux distributions
> are not affected, and in particular I have not had any gdb problems
> with the synthetic target under Fedora. So either:
>
>   a) the Debian/Ubuntu builds of gdb incorporate a dodgy patch, or
>   b) mainline gdb is broken, but Fedora and other distributions
>      incorporate a patch that fixes the problem.
>
>   So looking at the source packages for each distribution could help.
> Actually figuring out exactly what in eCos causes the internal error
> would also help. Either way this should really be fixed in the
> Debian/Ubuntu world, not inside eCos. If somebody investigates further
> and provides a harmless patch to the synthetic target which bypasses
> the problem, that would be acceptable as well - but note the
> "harmless".
>
>   Again I am not currently planning to work on this. Some
> Debian/Ubuntu user needs to step up to the plate.
>   

That was exactly the issue I was talking about. I guess I'll have to dig 
in and compare the source packages of Debian vs. Fedora as you proposed. 
I'll do this when I get some spare time, or I'll have a look at Fedora 
:) Do you guys at eCosCentric use Fedora as your primary Linux distribution?

Thanks for the information, I'll keep you updated.

Simon