Ping.
On 30/04/18 08:26, Sebastian Huber wrote:
On 17/04/18 12:30, Chris Johns wrote:
On 26/3/18 7:09 pm, Sebastian Huber wrote:
On 26/03/18 00:50, Chris Johns wrote:
On 14/03/2018 17:20, Sebastian Huber wrote:
On 13/03/18 22:58, Chris Johns wrote:
On 09/03/2018 19:55, Sebastian Huber wrote
Add support in tester to run covoar and generate an html report to display
the summary of the coverage reports generated from covoar.
Co-authored-by : Cillian O'Donnell
---
.gitignore| 1 +
tester/rt/coverage.py | 385
On Mon, 4 Jun 2018, 21:20 Vijay Kumar Banerjee,
wrote:
> On 5 June 2018 at 01:28, Cillian O'Donnell wrote:
>
>>
>>
>> On 4 June 2018 at 20:29, Vijay Kumar Banerjee
>> wrote:
>>
>>> On 5 June 2018 at 00:51, Joel Sherrill wrote:
>>>
On Mon, Jun 4, 2018 at 2:12 PM, Vijay Kumar Bane
On 5 June 2018 at 01:28, Cillian O'Donnell wrote:
>
>
> On 4 June 2018 at 20:29, Vijay Kumar Banerjee
> wrote:
>
>> On 5 June 2018 at 00:51, Joel Sherrill wrote:
>>
>>>
>>>
>>> On Mon, Jun 4, 2018 at 2:12 PM, Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>
On 5 June 2018 at
On Mon, Jun 4, 2018 at 2:27 PM, Walter Lee wrote:
> Hi Gedare. Thanks for the response. I am using a snapshot of RTEMS
> provided by a third party, based on commit #821acce on master. The
> bug should still be there on the tip of master and on 4.11 (and
> probably 4.10 also, but that version s
On 4 June 2018 at 20:29, Vijay Kumar Banerjee
wrote:
> On 5 June 2018 at 00:51, Joel Sherrill wrote:
>
>>
>>
>> On Mon, Jun 4, 2018 at 2:12 PM, Vijay Kumar Banerjee <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> On 5 June 2018 at 00:31, Joel Sherrill wrote:
>>>
I will add that covoar was ori
On Mon, Jun 4, 2018 at 2:29 PM, Vijay Kumar Banerjee <
vijaykumar9...@gmail.com> wrote:
> On 5 June 2018 at 00:51, Joel Sherrill wrote:
>
>>
>>
>> On Mon, Jun 4, 2018 at 2:12 PM, Vijay Kumar Banerjee <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> On 5 June 2018 at 00:31, Joel Sherrill wrote:
>>>
>
On 5 June 2018 at 00:51, Joel Sherrill wrote:
>
>
> On Mon, Jun 4, 2018 at 2:12 PM, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> On 5 June 2018 at 00:31, Joel Sherrill wrote:
>>
>>> I will add that covoar was originally designed to generate a report on
>>> one
>>> set at a time
On Mon, Jun 4, 2018 at 2:12 PM, Vijay Kumar Banerjee <
vijaykumar9...@gmail.com> wrote:
> On 5 June 2018 at 00:31, Joel Sherrill wrote:
>
>> I will add that covoar was originally designed to generate a report on one
>> set at a time. The iteration over symbol sets was done at the scripting
>> lev
On 5 June 2018 at 00:31, Joel Sherrill wrote:
> I will add that covoar was originally designed to generate a report on one
> set at a time. The iteration over symbol sets was done at the scripting
> level above that.
>
> This had the advantage of being simple at the time. It may still be simple
>
I will add that covoar was originally designed to generate a report on one
set at a time. The iteration over symbol sets was done at the scripting
level above that.
This had the advantage of being simple at the time. It may still be simple
but moving the iteration over sets to covoar will probably
On 4 June 2018 at 19:03, Vijay Kumar Banerjee
wrote:
> On 2 June 2018 at 01:00, Vijay Kumar Banerjee
> wrote:
>
>> On 2 June 2018 at 00:48, Joel Sherrill wrote:
>>
>>>
>>>
>>> On Fri, Jun 1, 2018, 11:21 AM Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>
On 1 June 2018 at 20
On 2 June 2018 at 01:00, Vijay Kumar Banerjee
wrote:
> On 2 June 2018 at 00:48, Joel Sherrill wrote:
>
>>
>>
>> On Fri, Jun 1, 2018, 11:21 AM Vijay Kumar Banerjee <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> On 1 June 2018 at 20:30, Gedare Bloom wrote:
>>>
On Fri, Jun 1, 2018 at 10:28 AM,
- Am 4. Jun 2018 um 16:43 schrieb joel j...@rtems.org:
> On Mon, Jun 4, 2018 at 9:36 AM, Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
>
>> - Am 4. Jun 2018 um 16:27 schrieb joel j...@rtems.org:
>>
>> > On Mon, Jun 4, 2018 at 9:14 AM, Gedare Bloom wrote:
>> >
>> >> Indee
On Mon, Jun 4, 2018 at 9:36 AM, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> - Am 4. Jun 2018 um 16:27 schrieb joel j...@rtems.org:
>
> > On Mon, Jun 4, 2018 at 9:14 AM, Gedare Bloom wrote:
> >
> >> Indeed, this 'rtc' shell command seems to be a bit of a misnomer. It
> >> co
- Am 4. Jun 2018 um 16:27 schrieb joel j...@rtems.org:
> On Mon, Jun 4, 2018 at 9:14 AM, Gedare Bloom wrote:
>
>> Indeed, this 'rtc' shell command seems to be a bit of a misnomer. It
>> conflates access to two different clocks, the tod and rtc. Probably,
>> it would be better to provide a se
On Mon, Jun 4, 2018 at 9:14 AM, Gedare Bloom wrote:
> Indeed, this 'rtc' shell command seems to be a bit of a misnomer. It
> conflates access to two different clocks, the tod and rtc. Probably,
> it would be better to provide a separate 'tod' command that
> reads/writes the tod values, and refact
Indeed, this 'rtc' shell command seems to be a bit of a misnomer. It
conflates access to two different clocks, the tod and rtc. Probably,
it would be better to provide a separate 'tod' command that
reads/writes the tod values, and refactor this 'rtc' to read/write the
rtc. I'm not quite sure about
Hello Walter,
Thank you for the bug report and patch. The patch is outdated, what
version of RTEMS are you using? I think the problem also affects the
master branch, but we need a ticket for each affected open branch.
The fix looks OK to me, but I'd like Chris Johns to approve it. I
assigned the
On Mon, Jun 4, 2018 at 5:44 AM, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
>
>
> - Am 4. Jun 2018 um 12:20 schrieb Amaan Cheval amaan.che...@gmail.com:
>
> > That's a good idea. That way based on the multilib variant, Newlib would
> be
> > compiled using fPIC, yes?
>
> Yes.
>
- Am 4. Jun 2018 um 12:20 schrieb Amaan Cheval amaan.che...@gmail.com:
> That's a good idea. That way based on the multilib variant, Newlib would be
> compiled using fPIC, yes?
Yes.
>
> Then I could simply figure out how to solve the crtbegin and crtend dilemma
> (which I believe should
That's a good idea. That way based on the multilib variant, Newlib would be
compiled using fPIC, yes?
Then I could simply figure out how to solve the crtbegin and crtend dilemma
(which I believe should be easier), and use those to have a dynamic/shared
RTEMS kernel + user application.
If that sou
Hello Amaan,
can't you add a new multilib variant which includes -fPIC to the GCC
configuration for RTEMS?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Hi!
I figured I'd quickly confirm the direction I'm taking towards
compiling RTEMS as a dynamic/shared library.
Problems I've run into in setting up amd64.cfg to compile all of RTEMS
as a shared library:
- In the x86_64 tools, gcc's "-shared" flag has a different effect
than the "-Wl,-shared" fl
24 matches
Mail list logo
