On 30/10/2014 10:49 am, Joel Sherrill wrote:
+ Run-Time Loader merged and tested
A patch has been posted but it needs at least a v2 before being merged.
I need to add tests and this needs a tool to generate a suitable kernel
symbol table. I am working on adding this to the rtems-syms tool i
Due to last minute scheduling conflicts on the volunteers doing this, the
relocation is Noe scheduled to occur next Tuesday and Wednesday (4 -5 November)
with possible extension if issues arise.
--joel
On October 29, 2014 10:22:27 AM CDT, Joel Sherrill
wrote:
>Hi
>
>Some of you may have proba
On October 29, 2014 6:35:54 PM CDT, Chris Johns wrote:
>On 30/10/2014 8:49 am, Joel Sherrill wrote:
>> Mandatory
>> ==
>> + Tool version selection
>> - Likely gcc 4.9 on almost all targets.
>
>All but m32c and h8300 ?
Yes AFAIK.
>> - binutils last release
>> - newlib TBD
>
On 30/10/2014 8:49 am, Joel Sherrill wrote:
Mandatory
==
+ Tool version selection
- Likely gcc 4.9 on almost all targets.
All but m32c and h8300 ?
- binutils last release
- newlib TBD
What happened about the snapshots ?
- GDB could be new release
Patches need upd
Hi
Since we are long over due for a release. I can count 4 new children
and a grandchild among the core developers since 4.10. :)
Here is what I have off the top of my head:
Mandatory
==
+ Tool version selection
- Likely gcc 4.9 on almost all targets.
- binutils last release
-
On 30/10/2014 8:06 am, Joel Sherrill wrote:
On 10/29/2014 4:01 PM, Gedare Bloom wrote:
On Wed, Oct 29, 2014 at 2:42 PM, Joel Sherrill
wrote:
Hi
As Jennifer has reviewed the output from an SMP capture
test, it is clear that something which was no big deal in
the old fixed record uniprocessor
On 10/29/2014 4:01 PM, Gedare Bloom wrote:
> On Wed, Oct 29, 2014 at 2:42 PM, Joel Sherrill
> wrote:
>> Hi
>>
>> As Jennifer has reviewed the output from an SMP capture
>> test, it is clear that something which was no big deal in
>> the old fixed record uniprocessor version is now an issue.
>> Mo
On Wed, Oct 29, 2014 at 2:42 PM, Joel Sherrill
wrote:
> Hi
>
> As Jennifer has reviewed the output from an SMP capture
> test, it is clear that something which was no big deal in
> the old fixed record uniprocessor version is now an issue.
> Most extensions have an "actor" and "acted upon" thread.
On 10/29/2014 3:49 PM, Hesham Moustafa wrote:
> Hi,
>
> Sorry for the false alarm, it seems to be due to some rebasing issues.
> I forked a vanilla repo and it builds fine with/without POSIX enabled.
>
Thanks for double checking.
> Regards,
> Hesham
>
> On Wed, Oct 29, 2014 at 8:37 PM, Joel Sherri
Hi,
Sorry for the false alarm, it seems to be due to some rebasing issues.
I forked a vanilla repo and it builds fine with/without POSIX enabled.
Regards,
Hesham
On Wed, Oct 29, 2014 at 8:37 PM, Joel Sherrill
wrote:
>
> On 10/25/2014 8:57 AM, Hesham Moustafa wrote:
>
> Hi,
>
> The exact error
Original Message
Subject:[ANNOUNCEMENT] GDB 7.8.1 released!
Date: Wed, 29 Oct 2014 15:34:53 -0500
From: Joel Brobecker
Reply-To: g...@sourceware.org
To: g...@sourceware.org
GDB 7.8.1 released!
Release 7.8.1 of GDB, the GNU Debugger, is n
Hi
As Jennifer has reviewed the output from an SMP capture
test, it is clear that something which was no big deal in
the old fixed record uniprocessor version is now an issue.
Most extensions have an "actor" and "acted upon" thread.
For example, when a task is created, the calling task and
new tas
On 10/25/2014 8:57 AM, Hesham Moustafa wrote:
> Hi,
>
> The exact error occurs with or1k port, even with --enable-posix and
> after Sebastian's fix commit. Any idea how to fix this?
>
Can you give me your configure command?
I tried with POSIX enabled and disabled and built all tests in both
cases
Hi,
I have a BSP almost identical to STM32F4 except I want a slight change
to the linker settings (I want to offset the start location because
there is a bootloader at location 0).
Two questions:
- Is there any way to do this other than to
a) duplicate the BSP and change just the linker fil
Hi
Some of you may have probably heard me talk about it but we have
a new stack of machines at Oregon State University's Open Source
Laboratory (https://osuosl.org/). The machines were paid for with
donations from years of Google Summer of Code and Google Code-In
participation. OSU OSL is on the
On 10/29/2014 10:03 AM, Мороз Олег wrote:
looks like the BSS segment is depend from RAM_SIZE. I'm changing file
called linkcmds:
MEMORY {
RAM_INT : ORIGIN = 0x2000, LENGTH = 128k
after building has
arm-rtems4.11-size shell.exe
text databssdechex
looks like the BSS segment is depend from RAM_SIZE. I'm changing file
called linkcmds:
MEMORY {
RAM_INT : ORIGIN = 0x2000, LENGTH = 128k
after building has
arm-rtems4.11-size shell.exe
text databssdechexfilename
364756 32256 98824 495
17 matches
Mail list logo
