Re: Many BSPs Fail to link CXX tests

[Joel Sherrill]

On Tue, Jan 5, 2016 at 7:57 PM, Gedare Bloom  wrote:

> The part about testing with a simulator is vague. But you can go ahead
> and generate tasks. Create 1 task per architecture that remains, and
> allow 5 instances for each.
>
>
Huh? How about one per BSP Family? If we do it the way you suggest,
we will have to assign BSPs to each student as they go.

I have not gotten close to perfect at using the right reply-to address. :(


> On Tue, Jan 5, 2016 at 4:17 PM, Joel Sherrill  wrote:
> >
> >
> > On Tue, Jan 5, 2016 at 2:39 PM, Gedare Bloom  wrote:
> >>
> >> On Tue, Jan 5, 2016 at 3:11 PM, Joel Sherrill  wrote:
> >> >
> >> >
> >> > On Tue, Jan 5, 2016 at 1:33 PM, Gedare Bloom 
> wrote:
> >> >>
> >> >> >> It might be good to create GCI tasks for students to get RTEMS
> >> >> >> Tester
> >> >> >> working for a few simulator targets that are supported?
> >> >> >>
> >> >> >
> >> >> > I could be wrong but I think I created them for all gdb based
> >> >> > simulators.
> >> >> > There is unlikely much low hanging fruit.
> >> >> >
> >> >> I just meant a task to run the Tester for some target that is a
> >> >> candidate for the follow-on work. That gives the potential students a
> >> >> baseline.
> >> >
> >> >
> >> > Oh... I actually wrote a task for a GCI student to do this. :)
> >> >
> >> > https://devel.rtems.org/wiki/GCI/Coding/AddPerSectionSupportToBSPs
> >> >
> >> > What do you think?
> >> >
> >> Save the page?
> >
> >
> > Sorry. I am glad I didn't lose it in that length of time. I am still at
> home
> > for the holidays and had to find a cat in the attic and then take a
> shower.
> > :(
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Many BSPs Fail to link CXX tests

[Sebastian Huber]

On 04/01/16 03:47, Joel Sherrill wrote:



On Sun, Jan 3, 2016 at 8:26 PM, Chris Johns > wrote:


On 01/04/16 12:55, Joel Sherrill wrote:

On SPARC/SIS, the main lesson I learned is that if the executable
dropped to something ridiculously small, then something was
broken. I
had one iteration where hello.exe had 48 bytes of code. :)


Nice work.


That much was pretty obvious. Why was a problem. :)


Any thoughts on how to catch breakages on BSPs we can only link?


Can you get a suitable list of functions that must be present in
the executable and check they are present with nm?


It should be simple if the breakage is between the entry point and the 
rest of the BSP. If hello does not include bsp_start() or 
rtems_initialize_data_structures(), then it is known to be broken. 
This is what broke on sis -- the first 16 instructions of the start 
code had no dependency on anything else. So the linkages were 
satisfied and nothing else pulled in. :)


I think this is a good thing to try to sweep in for 4.12 since
we can
easily check 4.11 vs 4.12 for breakages on specific BSPs.


So this is a once only check and not something we always check for?


Should be one time only. If the linkage between the start code and C 
code is correct, it will stay correct. Once you get to C code, 
everything should be magically correct.


I think this is simple enough in principle where it could be written 
up as a series of GCI tasks. One task per BSP given the amount of 
time. It isn't much editing but I would want


(1) patch to make/custom/XXX.cfg

(2) the commit message to include:
+ base size for some tests like hello and ticker (same on all BSPs)
+ new size for the same tests

(3) Confirmation with hello.num posted to GCI task so we can see the 
symbols ourselves. But they should have checked it.


OTOH, one of us could probably sweep the argument changes into the 
custom files quickly, my build scripts capture the size of the tests 
already, and we are used to scripting and automated passes.  Maybe I 
should play the next couple of weeks. If someone wants to help, it 
would be nice to have some.


I am in favour to enable this for all BSPs. Basically the linker scripts 
must have the KEEP () directive for the relevant sections. So, for a 
symbol test we should pick up one using the network stack and one using 
a global C++ constructor.


Do we really have to patch all the XXX.cfg files? Maybe wait until we 
have a new build system and add this to a common place?


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Many BSPs Fail to link CXX tests

[Gedare Bloom]

On Tue, Jan 5, 2016 at 5:35 AM, Sebastian Huber
 wrote:
>
>
> On 04/01/16 03:47, Joel Sherrill wrote:
>>
>>
>>
>> On Sun, Jan 3, 2016 at 8:26 PM, Chris Johns > > wrote:
>>
>> On 01/04/16 12:55, Joel Sherrill wrote:
>>
>> On SPARC/SIS, the main lesson I learned is that if the executable
>> dropped to something ridiculously small, then something was
>> broken. I
>> had one iteration where hello.exe had 48 bytes of code. :)
>>
>>
>> Nice work.
>>
>>
>> That much was pretty obvious. Why was a problem. :)
>>
>>
>> Any thoughts on how to catch breakages on BSPs we can only link?
>>
>>
>> Can you get a suitable list of functions that must be present in
>> the executable and check they are present with nm?
>>
>>
>> It should be simple if the breakage is between the entry point and the
>> rest of the BSP. If hello does not include bsp_start() or
>> rtems_initialize_data_structures(), then it is known to be broken. This is
>> what broke on sis -- the first 16 instructions of the start code had no
>> dependency on anything else. So the linkages were satisfied and nothing else
>> pulled in. :)
>>
>> I think this is a good thing to try to sweep in for 4.12 since
>> we can
>> easily check 4.11 vs 4.12 for breakages on specific BSPs.
>>
>>
>> So this is a once only check and not something we always check for?
>>
>>
>> Should be one time only. If the linkage between the start code and C code
>> is correct, it will stay correct. Once you get to C code, everything should
>> be magically correct.
>>
>> I think this is simple enough in principle where it could be written up as
>> a series of GCI tasks. One task per BSP given the amount of time. It isn't
>> much editing but I would want
>>
>> (1) patch to make/custom/XXX.cfg
>>
>> (2) the commit message to include:
>> + base size for some tests like hello and ticker (same on all BSPs)
>> + new size for the same tests
>>
>> (3) Confirmation with hello.num posted to GCI task so we can see the
>> symbols ourselves. But they should have checked it.
>>
>> OTOH, one of us could probably sweep the argument changes into the custom
>> files quickly, my build scripts capture the size of the tests already, and
>> we are used to scripting and automated passes.  Maybe I should play the next
>> couple of weeks. If someone wants to help, it would be nice to have some.
>
>
> I am in favour to enable this for all BSPs. Basically the linker scripts
> must have the KEEP () directive for the relevant sections. So, for a symbol
> test we should pick up one using the network stack and one using a global
> C++ constructor.
>
> Do we really have to patch all the XXX.cfg files? Maybe wait until we have a
> new build system and add this to a common place?
>
That works if we know all work. To validate incrementally the best
approach is to go through the .cfg files.

> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Many BSPs Fail to link CXX tests

[Gedare Bloom]

On Mon, Jan 4, 2016 at 1:23 PM, Joel Sherrill  wrote:
>
>
> On Sun, Jan 3, 2016 at 11:00 PM, Gedare Bloom  wrote:
>>
>> On Sun, Jan 3, 2016 at 9:47 PM, Joel Sherrill  wrote:
>> >
>> >
>> > On Sun, Jan 3, 2016 at 8:26 PM, Chris Johns  wrote:
>> >> Can you get a suitable list of functions that must be present in the
>> >> executable and check they are present with nm?
>> >>
>> >
>> > It should be simple if the breakage is between the entry point and the
>> > rest
>> > of the BSP. If hello does not include bsp_start() or
>> > rtems_initialize_data_structures(), then it is known to be broken. This
>> > is
>> > what broke on sis -- the first 16 instructions of the start code had no
>> > dependency on anything else. So the linkages were satisfied and nothing
>> > else
>> > pulled in. :)
>> >
>> Such a list should be easy enough to create by building every BSP and
>> creating a list of functions appearing in every one (known to run).
>>
>
> The scripts in rtems-testing/rtems keep a copy of ticker.ralf named
> CPU-BSP-ticker.ralf. For the ones I had laying around that were actually
> in ELF format with symbols still, there were 362 symbols which showed
> up in 68 files (that appears to be the magic maximum number).
>
>
> file *.ralf | grep ELF | cut -d':' -f1 | while read f
> do
>   target=`echo $f | cut -d'-' -f1`
>   mynm=${target}rtems4.12-nm
>
>   nm -g ${f} | grep " T " | cut -d' ' -f3
> done | sort | uniq -c | sort -n
>
https://codein.withgoogle.com/dashboard/tasks/4928162941108224/

Perhaps a GCI student will write something suitable to use for sanity checking.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Many BSPs Fail to link CXX tests

[Gedare Bloom]

>> It might be good to create GCI tasks for students to get RTEMS Tester
>> working for a few simulator targets that are supported?
>>
>
> I could be wrong but I think I created them for all gdb based simulators.
> There is unlikely much low hanging fruit.
>
I just meant a task to run the Tester for some target that is a
candidate for the follow-on work. That gives the potential students a
baseline.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Many BSPs Fail to link CXX tests

[Gedare Bloom]

On Tue, Jan 5, 2016 at 1:10 PM, Joel Sherrill  wrote:
>
> On Jan 5, 2016 4:35 AM, "Sebastian Huber"
>  wrote:
>>
>>
>>
>> On 04/01/16 03:47, Joel Sherrill wrote:
>>
>>>
>>>
>>> On Sun, Jan 3, 2016 at 8:26 PM, Chris Johns >> > wrote:
>>>
>>> On 01/04/16 12:55, Joel Sherrill wrote:
>>>
>>> On SPARC/SIS, the main lesson I learned is that if the executable
>>> dropped to something ridiculously small, then something was
>>> broken. I
>>> had one iteration where hello.exe had 48 bytes of code. :)
>>>
>>>
>>> Nice work.
>>>
>>>
>>> That much was pretty obvious. Why was a problem. :)
>>>
>>>
>>> Any thoughts on how to catch breakages on BSPs we can only link?
>>>
>>>
>>> Can you get a suitable list of functions that must be present in
>>> the executable and check they are present with nm?
>>>
>>>
>>> It should be simple if the breakage is between the entry point and the
>>> rest of the BSP. If hello does not include bsp_start() or
>>> rtems_initialize_data_structures(), then it is known to be broken. This is
>>> what broke on sis -- the first 16 instructions of the start code had no
>>> dependency on anything else. So the linkages were satisfied and nothing else
>>> pulled in. :)
>>>
>>> I think this is a good thing to try to sweep in for 4.12 since
>>> we can
>>> easily check 4.11 vs 4.12 for breakages on specific BSPs.
>>>
>>>
>>> So this is a once only check and not something we always check for?
>>>
>>>
>>> Should be one time only. If the linkage between the start code and C code
>>> is correct, it will stay correct. Once you get to C code, everything should
>>> be magically correct.
>>>
>>> I think this is simple enough in principle where it could be written up
>>> as a series of GCI tasks. One task per BSP given the amount of time. It
>>> isn't much editing but I would want
>>>
>>> (1) patch to make/custom/XXX.cfg
>>>
>>> (2) the commit message to include:
>>> + base size for some tests like hello and ticker (same on all BSPs)
>>> + new size for the same tests
>>>
>>> (3) Confirmation with hello.num posted to GCI task so we can see the
>>> symbols ourselves. But they should have checked it.
>>>
>>> OTOH, one of us could probably sweep the argument changes into the custom
>>> files quickly, my build scripts capture the size of the tests already, and
>>> we are used to scripting and automated passes.  Maybe I should play the next
>>> couple of weeks. If someone wants to help, it would be nice to have some.
>>
>>
>> I am in favour to enable this for all BSPs. Basically the linker scripts
>> must have the KEEP () directive for the relevant sections. So, for a symbol
>> test we should pick up one using the network stack and one using a global
>> C++ constructor.About 60 BSPs have test linkage failures now due to size
>> overflows. I see this as either edit .tcfg files and ignore tests which
>> could actually fit with per section magic or edit the .cfg file and move
>> forward.
>
> One question is about the approach for bsp families with many variants and a
> .inc file. It is easy to add the options to the .inc file and cover all
> variants. Is that OK with everyone? It sure reduces the effort.
>
> FWIW the SPARC bsps broke due to a missing dependency from the start code
> not C++ or the linker set. This is more what I am concerned about. The ones
> you mentioned should be easily checked with a grep on linker scripts.
>
>> Do we really have to patch all the XXX.cfg files? Maybe wait until we have
>> a new build system and add this to a common place?
>
> At the moment, I can edit ~60 .tcfg or not that many more .cfg/.inc files
> and likely solve the problem. I lean to the long-term solution. I don't see
> waiting.
>
> Looking at it another way, this was trialed in 4.11 with sparc BSPs.
> Historically, we have precedence for improving some BSPs in one release and
> sweeping something in place in the next. Makes sense to do this from that
> perspective.
>
I say write this up as GCI tasks. Probably sweep the linkcmds first to
add KEEP directives for each architecture. Then, each architecture can
be converted to *-sections as a task. Functional validation should be
performed with a simulator where possible, and RTEMS Tester should be
used if available.

It might be good to create GCI tasks for students to get RTEMS Tester
working for a few simulator targets that are supported?

>
> --joel
>
>
>> --
>> Sebastian Huber, embedded brains GmbH
>>
>> Address : Dornierstr. 4, D-82178 Puchheim, Germany
>> Phone   : +49 89 189 47 41-16
>> Fax : +49 89 189 47 41-09
>> E-Mail  : sebastian.hu...@embedded-brains.de
>> PGP : Public key available on request.
>>
>> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>>
>
>
> ___
> devel mailing list
> devel@rtems.org
> 

Re: Many BSPs Fail to link CXX tests

[Joel Sherrill]

On Tue, Jan 5, 2016 at 12:54 PM, Gedare Bloom  wrote:

> On Tue, Jan 5, 2016 at 1:10 PM, Joel Sherrill  wrote:
> >
> > On Jan 5, 2016 4:35 AM, "Sebastian Huber"
> >  wrote:
> >>
> >>
> >>
> >> On 04/01/16 03:47, Joel Sherrill wrote:
> >>
> >>>
> >>>
> >>> On Sun, Jan 3, 2016 at 8:26 PM, Chris Johns  >>> > wrote:
> >>>
> >>> On 01/04/16 12:55, Joel Sherrill wrote:
> >>>
> >>> On SPARC/SIS, the main lesson I learned is that if the
> executable
> >>> dropped to something ridiculously small, then something was
> >>> broken. I
> >>> had one iteration where hello.exe had 48 bytes of code. :)
> >>>
> >>>
> >>> Nice work.
> >>>
> >>>
> >>> That much was pretty obvious. Why was a problem. :)
> >>>
> >>>
> >>> Any thoughts on how to catch breakages on BSPs we can only
> link?
> >>>
> >>>
> >>> Can you get a suitable list of functions that must be present in
> >>> the executable and check they are present with nm?
> >>>
> >>>
> >>> It should be simple if the breakage is between the entry point and the
> >>> rest of the BSP. If hello does not include bsp_start() or
> >>> rtems_initialize_data_structures(), then it is known to be broken.
> This is
> >>> what broke on sis -- the first 16 instructions of the start code had no
> >>> dependency on anything else. So the linkages were satisfied and
> nothing else
> >>> pulled in. :)
> >>>
> >>> I think this is a good thing to try to sweep in for 4.12 since
> >>> we can
> >>> easily check 4.11 vs 4.12 for breakages on specific BSPs.
> >>>
> >>>
> >>> So this is a once only check and not something we always check for?
> >>>
> >>>
> >>> Should be one time only. If the linkage between the start code and C
> code
> >>> is correct, it will stay correct. Once you get to C code, everything
> should
> >>> be magically correct.
> >>>
> >>> I think this is simple enough in principle where it could be written up
> >>> as a series of GCI tasks. One task per BSP given the amount of time. It
> >>> isn't much editing but I would want
> >>>
> >>> (1) patch to make/custom/XXX.cfg
> >>>
> >>> (2) the commit message to include:
> >>> + base size for some tests like hello and ticker (same on all BSPs)
> >>> + new size for the same tests
> >>>
> >>> (3) Confirmation with hello.num posted to GCI task so we can see the
> >>> symbols ourselves. But they should have checked it.
> >>>
> >>> OTOH, one of us could probably sweep the argument changes into the
> custom
> >>> files quickly, my build scripts capture the size of the tests already,
> and
> >>> we are used to scripting and automated passes.  Maybe I should play
> the next
> >>> couple of weeks. If someone wants to help, it would be nice to have
> some.
> >>
> >>
> >> I am in favour to enable this for all BSPs. Basically the linker scripts
> >> must have the KEEP () directive for the relevant sections. So, for a
> symbol
> >> test we should pick up one using the network stack and one using a
> global
> >> C++ constructor.About 60 BSPs have test linkage failures now due to size
> >> overflows. I see this as either edit .tcfg files and ignore tests which
> >> could actually fit with per section magic or edit the .cfg file and move
> >> forward.
> >
> > One question is about the approach for bsp families with many variants
> and a
> > .inc file. It is easy to add the options to the .inc file and cover all
> > variants. Is that OK with everyone? It sure reduces the effort.
> >
> > FWIW the SPARC bsps broke due to a missing dependency from the start code
> > not C++ or the linker set. This is more what I am concerned about. The
> ones
> > you mentioned should be easily checked with a grep on linker scripts.
> >
> >> Do we really have to patch all the XXX.cfg files? Maybe wait until we
> have
> >> a new build system and add this to a common place?
> >
> > At the moment, I can edit ~60 .tcfg or not that many more .cfg/.inc files
> > and likely solve the problem. I lean to the long-term solution. I don't
> see
> > waiting.
> >
> > Looking at it another way, this was trialed in 4.11 with sparc BSPs.
> > Historically, we have precedence for improving some BSPs in one release
> and
> > sweeping something in place in the next. Makes sense to do this from that
> > perspective.
> >
> I say write this up as GCI tasks. Probably sweep the linkcmds first to
> add KEEP directives for each architecture. Then, each architecture can
> be converted to *-sections as a task. Functional validation should be
> performed with a simulator where possible, and RTEMS Tester should be
> used if available.
>
>
I will try to get to this. We also could use one for deleting the m68k/idp
BSP
and a ticket.


> It might be good to create GCI tasks for students to get RTEMS Tester
> working for a few simulator targets that are supported?
>
>
I could be wrong but I think I created 

Re: Many BSPs Fail to link CXX tests

[Joel Sherrill]

On Jan 5, 2016 4:35 AM, "Sebastian Huber" <
sebastian.hu...@embedded-brains.de> wrote:
>
>
>
> On 04/01/16 03:47, Joel Sherrill wrote:
>
>>
>>
>> On Sun, Jan 3, 2016 at 8:26 PM, Chris Johns  wrote:
>>
>> On 01/04/16 12:55, Joel Sherrill wrote:
>>
>> On SPARC/SIS, the main lesson I learned is that if the executable
>> dropped to something ridiculously small, then something was
>> broken. I
>> had one iteration where hello.exe had 48 bytes of code. :)
>>
>>
>> Nice work.
>>
>>
>> That much was pretty obvious. Why was a problem. :)
>>
>>
>> Any thoughts on how to catch breakages on BSPs we can only link?
>>
>>
>> Can you get a suitable list of functions that must be present in
>> the executable and check they are present with nm?
>>
>>
>> It should be simple if the breakage is between the entry point and the
rest of the BSP. If hello does not include bsp_start() or
rtems_initialize_data_structures(), then it is known to be broken. This is
what broke on sis -- the first 16 instructions of the start code had no
dependency on anything else. So the linkages were satisfied and nothing
else pulled in. :)
>>
>> I think this is a good thing to try to sweep in for 4.12 since
>> we can
>> easily check 4.11 vs 4.12 for breakages on specific BSPs.
>>
>>
>> So this is a once only check and not something we always check for?
>>
>>
>> Should be one time only. If the linkage between the start code and C
code is correct, it will stay correct. Once you get to C code, everything
should be magically correct.
>>
>> I think this is simple enough in principle where it could be written up
as a series of GCI tasks. One task per BSP given the amount of time. It
isn't much editing but I would want
>>
>> (1) patch to make/custom/XXX.cfg
>>
>> (2) the commit message to include:
>> + base size for some tests like hello and ticker (same on all BSPs)
>> + new size for the same tests
>>
>> (3) Confirmation with hello.num posted to GCI task so we can see the
symbols ourselves. But they should have checked it.
>>
>> OTOH, one of us could probably sweep the argument changes into the
custom files quickly, my build scripts capture the size of the tests
already, and we are used to scripting and automated passes.  Maybe I should
play the next couple of weeks. If someone wants to help, it would be nice
to have some.
>
>
> I am in favour to enable this for all BSPs. Basically the linker scripts
must have the KEEP () directive for the relevant sections. So, for a symbol
test we should pick up one using the network stack and one using a global
C++ constructor.About 60 BSPs have test linkage failures now due to size
overflows. I see this as either edit .tcfg files and ignore tests which
could actually fit with per section magic or edit the .cfg file and move
forward.

One question is about the approach for bsp families with many variants and
a .inc file. It is easy to add the options to the .inc file and cover all
variants. Is that OK with everyone? It sure reduces the effort.

FWIW the SPARC bsps broke due to a missing dependency from the start code
not C++ or the linker set. This is more what I am concerned about. The ones
you mentioned should be easily checked with a grep on linker scripts.

> Do we really have to patch all the XXX.cfg files? Maybe wait until we
have a new build system and add this to a common place?

At the moment, I can edit ~60 .tcfg or not that many more .cfg/.inc files
and likely solve the problem. I lean to the long-term solution. I don't see
waiting.

Looking at it another way, this was trialed in 4.11 with sparc BSPs.
Historically, we have precedence for improving some BSPs in one release and
sweeping something in place in the next. Makes sense to do this from that
perspective.


--joel


> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Many BSPs Fail to link CXX tests

[Joel Sherrill]

On Tue, Jan 5, 2016 at 1:33 PM, Gedare Bloom  wrote:

> >> It might be good to create GCI tasks for students to get RTEMS Tester
> >> working for a few simulator targets that are supported?
> >>
> >
> > I could be wrong but I think I created them for all gdb based simulators.
> > There is unlikely much low hanging fruit.
> >
> I just meant a task to run the Tester for some target that is a
> candidate for the follow-on work. That gives the potential students a
> baseline.
>

Oh... I actually wrote a task for a GCI student to do this. :)

https://devel.rtems.org/wiki/GCI/Coding/AddPerSectionSupportToBSPs

What do you think?

--joel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Many BSPs Fail to link CXX tests

[Joel Sherrill]

On Tue, Jan 5, 2016 at 2:39 PM, Gedare Bloom  wrote:

> On Tue, Jan 5, 2016 at 3:11 PM, Joel Sherrill  wrote:
> >
> >
> > On Tue, Jan 5, 2016 at 1:33 PM, Gedare Bloom  wrote:
> >>
> >> >> It might be good to create GCI tasks for students to get RTEMS Tester
> >> >> working for a few simulator targets that are supported?
> >> >>
> >> >
> >> > I could be wrong but I think I created them for all gdb based
> >> > simulators.
> >> > There is unlikely much low hanging fruit.
> >> >
> >> I just meant a task to run the Tester for some target that is a
> >> candidate for the follow-on work. That gives the potential students a
> >> baseline.
> >
> >
> > Oh... I actually wrote a task for a GCI student to do this. :)
> >
> > https://devel.rtems.org/wiki/GCI/Coding/AddPerSectionSupportToBSPs
> >
> > What do you think?
> >
> Save the page?
>

Sorry. I am glad I didn't lose it in that length of time. I am still at home
for the holidays and had to find a cat in the attic and then take a shower.
:(
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Many BSPs Fail to link CXX tests

[Gedare Bloom]

On Tue, Jan 5, 2016 at 3:11 PM, Joel Sherrill  wrote:
>
>
> On Tue, Jan 5, 2016 at 1:33 PM, Gedare Bloom  wrote:
>>
>> >> It might be good to create GCI tasks for students to get RTEMS Tester
>> >> working for a few simulator targets that are supported?
>> >>
>> >
>> > I could be wrong but I think I created them for all gdb based
>> > simulators.
>> > There is unlikely much low hanging fruit.
>> >
>> I just meant a task to run the Tester for some target that is a
>> candidate for the follow-on work. That gives the potential students a
>> baseline.
>
>
> Oh... I actually wrote a task for a GCI student to do this. :)
>
> https://devel.rtems.org/wiki/GCI/Coding/AddPerSectionSupportToBSPs
>
> What do you think?
>
Save the page?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Many BSPs Fail to link CXX tests

[Gedare Bloom]

The part about testing with a simulator is vague. But you can go ahead
and generate tasks. Create 1 task per architecture that remains, and
allow 5 instances for each.

On Tue, Jan 5, 2016 at 4:17 PM, Joel Sherrill  wrote:
>
>
> On Tue, Jan 5, 2016 at 2:39 PM, Gedare Bloom  wrote:
>>
>> On Tue, Jan 5, 2016 at 3:11 PM, Joel Sherrill  wrote:
>> >
>> >
>> > On Tue, Jan 5, 2016 at 1:33 PM, Gedare Bloom  wrote:
>> >>
>> >> >> It might be good to create GCI tasks for students to get RTEMS
>> >> >> Tester
>> >> >> working for a few simulator targets that are supported?
>> >> >>
>> >> >
>> >> > I could be wrong but I think I created them for all gdb based
>> >> > simulators.
>> >> > There is unlikely much low hanging fruit.
>> >> >
>> >> I just meant a task to run the Tester for some target that is a
>> >> candidate for the follow-on work. That gives the potential students a
>> >> baseline.
>> >
>> >
>> > Oh... I actually wrote a task for a GCI student to do this. :)
>> >
>> > https://devel.rtems.org/wiki/GCI/Coding/AddPerSectionSupportToBSPs
>> >
>> > What do you think?
>> >
>> Save the page?
>
>
> Sorry. I am glad I didn't lose it in that length of time. I am still at home
> for the holidays and had to find a cat in the attic and then take a shower.
> :(
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Many BSPs Fail to link CXX tests

[Joel Sherrill]

On Sun, Jan 3, 2016 at 11:00 PM, Gedare Bloom  wrote:

> On Sun, Jan 3, 2016 at 9:47 PM, Joel Sherrill  wrote:
> >
> >
> > On Sun, Jan 3, 2016 at 8:26 PM, Chris Johns  wrote:
> >> Can you get a suitable list of functions that must be present in the
> >> executable and check they are present with nm?
> >>
> >
> > It should be simple if the breakage is between the entry point and the
> rest
> > of the BSP. If hello does not include bsp_start() or
> > rtems_initialize_data_structures(), then it is known to be broken. This
> is
> > what broke on sis -- the first 16 instructions of the start code had no
> > dependency on anything else. So the linkages were satisfied and nothing
> else
> > pulled in. :)
> >
> Such a list should be easy enough to create by building every BSP and
> creating a list of functions appearing in every one (known to run).
>
>
The scripts in rtems-testing/rtems keep a copy of ticker.ralf named
CPU-BSP-ticker.ralf. For the ones I had laying around that were actually
in ELF format with symbols still, there were 362 symbols which showed
up in 68 files (that appears to be the magic maximum number).


file *.ralf | grep ELF | cut -d':' -f1 | while read f
do
  target=`echo $f | cut -d'-' -f1`
  mynm=${target}rtems4.12-nm

  nm -g ${f} | grep " T " | cut -d' ' -f3
done | sort | uniq -c | sort -n


There is no guarantee that those 362 symbols are actually really required
and turning on per-item section linking I hope would reduce that. Perhaps
a core list of BSP init, RTEMS init, application, and C library referenced
would be sufficient. For ticker or hello, this would be:

boot_card()
bsp_start()
rtems_initialize_data_structures()
Init()

If you managed to link enough to include Init() and this broke the
executable,
then I would expect a very subtle problem that nothing automated will find.
Something like leaving out interrupt vectors which we wouldn't be looking
for.

I am not even sure about printf() since gcc optimizes constant string prints
to puts() and the tests can be configured to use printk().

Any thoughts?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Many BSPs Fail to link CXX tests

[Joel Sherrill]

Replied from the wrong email address and it didn't go to the list. :(

Besides this is a longer reply with a reference to a spreadsheet with size
data for when I turned this on for the sparc BSPs.

On Sun, Jan 3, 2016 at 6:24 PM, Chris Johns  wrote:

> On 12/27/15 02:39, Joel Sherrill wrote:
>
>> I noticed in a build of all BSPs that a number have trouble
>> linking some of the larger tests. Rather than add them to
>> the tcfg files, is it time to turn on per-function/data item
>> linking to all the BSPs?
>>
>
> Does this work for architectures?
>
> Technically I have no idea. But I think so since this should be a generic
binutils/ld feature. If it doesn't work on a particular architecture, that
would be a tools bug to report upstream. And we obviously wouldn't use it
on that architecture.

> For C++ this makes sense but does it for C?

Yep. C++ really needs this.

> We have worked hard to break down our code into small pieces to ensure we
link only what is needed. My concern is per-function linking relaxes this
but it is important?. It becomes difficult to avoid doing this if it is
supported by an architecture because it works on all code including 3rd
party libraries which is a huge win.

When I experimented with doing this on the SPARC BSPs, I saw a large drop
in test executable sizes drop about 50% on average. So it does make
difference on C,  I found the spreadsheet I built for SPARC/SIS with and
without using the per function and data item sections. I apparently did
this in April 2013.

https://docs.google.com/spreadsheets/d/1XHCUqo6EJC08cKS4EgIRyAGabAhDr-7QbJbhQpVVooc/edit?usp=sharing
It looked like the tests were regularly 45-50% smaller. Even minimum
dropped.

Overall, I was quite shocked at how effective it was. I really wanted to
sweep it across all then. But I am a bit concerned that it breaks
something. I am now more cynical. If we break it and someone reports it, we
know of a user. If no one ever says anything, then we either didn't break
it or no one is using it. Either way, it is information and a point in time
we can use as a reference for future deprecation of BSPs.


--joel


Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Many BSPs Fail to link CXX tests

[Chris Johns]

On 01/04/16 12:55, Joel Sherrill wrote:

On SPARC/SIS, the main lesson I learned is that if the executable
dropped to something ridiculously small, then something was broken. I
had one iteration where hello.exe had 48 bytes of code. :)


Nice work.



Any thoughts on how to catch breakages on BSPs we can only link?



Can you get a suitable list of functions that must be present in the 
executable and check they are present with nm?



I think this is a good thing to try to sweep in for 4.12 since we can
easily check 4.11 vs 4.12 for breakages on specific BSPs.


So this is a once only check and not something we always check for?

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Many BSPs Fail to link CXX tests

[Chris Johns]

On 01/04/16 12:33, Joel Sherrill wrote:

Replied from the wrong email address and it didn't go to the list. :(

Besides this is a longer reply with a reference to a spreadsheet with
size data for when I turned this on for the sparc BSPs.

On Sun, Jan 3, 2016 at 6:24 PM, Chris Johns > wrote:

On 12/27/15 02:39, Joel Sherrill wrote:

I noticed in a build of all BSPs that a number have trouble
linking some of the larger tests. Rather than add them to
the tcfg files, is it time to turn on per-function/data item
linking to all the BSPs?


Does this work for architectures?

Technically I have no idea. But I think so since this should be a
generic binutils/ld feature. If it doesn't work on a particular
architecture, that would be a tools bug to report upstream. And we
obviously wouldn't use it on that architecture.



This makes sense.


 > For C++ this makes sense but does it for C?

Yep. C++ really needs this.

 > We have worked hard to break down our code into small pieces to
ensure we link only what is needed. My concern is per-function linking
relaxes this but it is important?. It becomes difficult to avoid doing
this if it is supported by an architecture because it works on all code
including 3rd party libraries which is a huge win.

When I experimented with doing this on the SPARC BSPs, I saw a large
drop in test executable sizes drop about 50% on average. So it does make
difference on C,  I found the spreadsheet I built for SPARC/SIS with and
without using the per function and data item sections. I apparently did
this in April 2013.

https://docs.google.com/spreadsheets/d/1XHCUqo6EJC08cKS4EgIRyAGabAhDr-7QbJbhQpVVooc/edit?usp=sharing

It looked like the tests were regularly 45-50% smaller. Even minimum
dropped.

Overall, I was quite shocked at how effective it was. I really wanted to
sweep it across all then. But I am a bit concerned that it breaks
something. I am now more cynical. If we break it and someone reports it,
we know of a user. If no one ever says anything, then we either didn't
break it or no one is using it. Either way, it is information and a
point in time we can use as a reference for future deprecation of BSPs.



Excellent and I agree. It is a nice feature and I agree we should use it.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Many BSPs Fail to link CXX tests

[Chris Johns]

On 12/27/15 02:39, Joel Sherrill wrote:

I noticed in a build of all BSPs that a number have trouble
linking some of the larger tests. Rather than add them to
the tcfg files, is it time to turn on per-function/data item
linking to all the BSPs?


Does this work for architectures?

For C++ this makes sense but does it for C? We have worked hard to break 
down our code into small pieces to ensure we link only what is needed. 
My concern is per-function linking relaxes this but it is important?. It 
becomes difficult to avoid doing this if it is supported by an 
architecture because it works on all code including 3rd party libraries 
which is a huge win.


Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Many BSPs Fail to link CXX tests

[Gedare Bloom]

On Sun, Jan 3, 2016 at 9:47 PM, Joel Sherrill  wrote:
>
>
> On Sun, Jan 3, 2016 at 8:26 PM, Chris Johns  wrote:
>>
>> On 01/04/16 12:55, Joel Sherrill wrote:
>>>
>>> On SPARC/SIS, the main lesson I learned is that if the executable
>>> dropped to something ridiculously small, then something was broken. I
>>> had one iteration where hello.exe had 48 bytes of code. :)
>>
>>
>> Nice work.
>>
>
> That much was pretty obvious. Why was a problem. :)
>>>
>>>
>>> Any thoughts on how to catch breakages on BSPs we can only link?
>>>
>>
>> Can you get a suitable list of functions that must be present in the
>> executable and check they are present with nm?
>>
>
> It should be simple if the breakage is between the entry point and the rest
> of the BSP. If hello does not include bsp_start() or
> rtems_initialize_data_structures(), then it is known to be broken. This is
> what broke on sis -- the first 16 instructions of the start code had no
> dependency on anything else. So the linkages were satisfied and nothing else
> pulled in. :)
>
Such a list should be easy enough to create by building every BSP and
creating a list of functions appearing in every one (known to run).

>>>
>>> I think this is a good thing to try to sweep in for 4.12 since we can
>>> easily check 4.11 vs 4.12 for breakages on specific BSPs.
>>
>>
>> So this is a once only check and not something we always check for?
>>
>
> Should be one time only. If the linkage between the start code and C code is
> correct, it will stay correct. Once you get to C code, everything should be
> magically correct.
>
> I think this is simple enough in principle where it could be written up as a
> series of GCI tasks. One task per BSP given the amount of time. It isn't
> much editing but I would want
>
> (1) patch to make/custom/XXX.cfg
>
> (2) the commit message to include:
> + base size for some tests like hello and ticker (same on all BSPs)
> + new size for the same tests
>
> (3) Confirmation with hello.num posted to GCI task so we can see the symbols
> ourselves. But they should have checked it.
>
> OTOH, one of us could probably sweep the argument changes into the custom
> files quickly, my build scripts capture the size of the tests already, and
> we are used to scripting and automated passes.  Maybe I should play the next
> couple of weeks. If someone wants to help, it would be nice to have some.
>
>>
>> Chris
>
>
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel