This is my first shot at disabling per-task variables when SMP
is enabled. Since there are still uses of per-task variables, this
breaks the SMP build. It cannot be applied until those are addressed.
Hoping that those uses disappear while I am in Munich next week,
I am posting this for review. :)
Dear Gedare,
Thank you for this notice.
I will follow up this on rtems bugzilla.
Best Regards,
JunBeom
-Original Message-
From: ged...@gwmail.gwu.edu [mailto:ged...@gwmail.gwu.edu] On Behalf Of
Gedare Bloom
Sent: Saturday, March 22, 2014 2:14 AM
To: JunBeom Kim (Coressent)
Cc: RTEMS Dev
On Fri, Mar 21, 2014 at 1:08 PM, JunBeom Kim (Coressent)
wrote:
> Dear Gedare,
>
> Thank you very much for your effort.
>
> As soon as RTEMS team resolve this, please let me know that.
>
Well, right now I can't look into this further. You may wish to file a
PR on RTEMS Bugzilla (https://www.rtems.
Dear Gedare,
Thank you very much for your effort.
As soon as RTEMS team resolve this, please let me know that.
Best Regards,
JunBeom
-Original Message-
From: ged...@gwmail.gwu.edu [mailto:ged...@gwmail.gwu.edu] On Behalf Of
Gedare Bloom
Sent: Saturday, March 22, 2014 1:59 AM
To: JunBeom
On Fri, Mar 21, 2014 at 12:45 PM, JunBeom Kim (Coressent)
wrote:
> Dear Gedare,
>
> After installing all toolset according to RSB, I rebuilt rtems source tree
> for SIS.
> When I check this, current problem is not resolved.
> I think that this problem is not related with toolchain by RSB.
>
OK, th
Dear Gedare,
After installing all toolset according to RSB, I rebuilt rtems source tree
for SIS.
When I check this, current problem is not resolved.
I think that this problem is not related with toolchain by RSB.
Please could you let me know another option for resolving this ?
Best Regards,
JunB
On Fri, Mar 21, 2014 at 11:12 AM, JunBeom Kim (Coressent)
wrote:
> Dear Gedare,
>
> Thank you for your reply.
>
> First of all, I set breakpoint in _Unwind_RaiseException. also, software
> crash is occurred in _Unwind_RaiseException function certainly.
>
> When I see location of address 0x02034A43
Dear Gedare,
Thank you for your reply.
First of all, I set breakpoint in _Unwind_RaiseException. also, software
crash is occurred in _Unwind_RaiseException function certainly.
When I see location of address 0x02034A43, it's location is
classify_object_over_fdes.
As I check google search with "cl
On Fri, Mar 21, 2014 at 9:32 AM, Sebastian Huber
wrote:
> Hello,
>
> I changed the objects allocate/free to use the allocator mutex. This change
> is very important since otherwise the thread dispatch latency depends on the
> heap fragmentation. I noticed now a problem with the thread priority q
On Fri, Mar 21, 2014 at 9:43 AM, Sebastian Huber
wrote:
> On 2014-03-21 14:32, Sebastian Huber wrote:
>>
>> Hello,
>>
>> I changed the objects allocate/free to use the allocator mutex. This
>> change is
>> very important since otherwise the thread dispatch latency depends on the
>> heap
>> fragme
On 2014-03-21 14:32, Sebastian Huber wrote:
Hello,
I changed the objects allocate/free to use the allocator mutex. This change is
very important since otherwise the thread dispatch latency depends on the heap
fragmentation. I noticed now a problem with the thread priority queues and the
EDF sc
Hello,
I changed the objects allocate/free to use the allocator mutex. This change is
very important since otherwise the thread dispatch latency depends on the heap
fragmentation. I noticed now a problem with the thread priority queues and the
EDF scheduler. The EDF scheduler uses priority
I've found another small bug in my patch: After removing the pthread
header from the gxx_wrapper.h in my second version of the patch I
forgot to add it to gxx_wrapper.c. This is fixed in the appended new
version of the third patch.
Sorry for the additional mails.
_
From: Christian Mauderer
With this patch C++ applications now eventually need additional POSIX-keys and
POSIX-key-value-pairs configured.
---
cpukit/libcsupport/include/rtems/gxx_wrappers.h | 8 +-
cpukit/libcsupport/src/gxx_wrappers.c | 112 +++-
testsuites/libte
From: Christian Mauderer
---
cpukit/librpc/include/rpc/rpc.h | 4 ++-
cpukit/librpc/src/rpc/rtems_rpc.c | 65 +--
2 files changed, 51 insertions(+), 18 deletions(-)
diff --git a/cpukit/librpc/include/rpc/rpc.h b/cpukit/librpc/include/rpc/rpc.h
index 95df08
Am 21.03.2014 13:30, schrieb Gedare Bloom:
> On Fri, Mar 21, 2014 at 5:26 AM, Christian Mauderer
> wrote:
>> From: Christian Mauderer
>>
>> With this patch C++ applications now eventually need additional POSIX-keys
>> and
>> POSIX-key-value-pairs configured.
> I'm not sure where, but this fact
On Fri, Mar 21, 2014 at 2:42 AM, JunBeom Kim (Coressent)
wrote:
> Dear Sir,
>
>
>
> After I built RTEMS kernel for Sparc SIS, I downloaded examples-v2.
>
> Also, I am testing cxx example.
>
>
>
> When I test cxx example on SIS, C++ exception(throw->catch) is not working.
>
> Console message is bel
Looks good.
On Fri, Mar 21, 2014 at 5:26 AM, Christian Mauderer
wrote:
> From: Christian Mauderer
>
> The man-page for pthread_setspecific does not define the EAGAIN return value.
> Further without this patch it was not possible to set keys that have been
> already set a new value.
> ---
> cpuk
On Fri, Mar 21, 2014 at 5:26 AM, Christian Mauderer
wrote:
> From: Christian Mauderer
>
> With this patch C++ applications now eventually need additional POSIX-keys and
> POSIX-key-value-pairs configured.
I'm not sure where, but this fact should be somewhere in user documentation.
> ---
> cpuki
From: Christian Mauderer
With this patch C++ applications now eventually need additional POSIX-keys and
POSIX-key-value-pairs configured.
---
cpukit/libcsupport/include/rtems/gxx_wrappers.h | 8 +-
cpukit/libcsupport/src/gxx_wrappers.c | 111 +++-
testsuites/libte
From: Christian Mauderer
The rtems_gxx_key_dtor function is not longer used by gcc.
---
cpukit/libcsupport/include/rtems/gxx_wrappers.h | 2 --
cpukit/libcsupport/src/gxx_wrappers.c | 10 --
testsuites/libtests/gxx01/gxx01.doc | 1 -
testsuites/libtests/gxx01/gxx0
On a suggestion from Sebastian I've changed two points:
- Add a testcase for calling pthread_setspecific two times with the same key.
- Remove one unnecessary include.
___
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listi
From: Christian Mauderer
The man-page for pthread_setspecific does not define the EAGAIN return value.
Further without this patch it was not possible to set keys that have been
already set a new value.
Add test for setting a new value to a already set key.
---
cpukit/posix/src/keysetspecific.c
On 2014-03-20 16:52, Joel Sherrill wrote:
Hi
The next batch of messages are patches that eliminate rtems_bsp_delay
in BSPs that do not have any use cases. The remaining uses are primarily
in the PowerPC and x86 BSPs. I left the code in the MIPS because it looked
useful for a CPU counter.
On th
From: Christian Mauderer
With this patch C++ applications now eventually need additional POSIX-keys and
POSIX-key-value-pairs configured.
---
cpukit/libcsupport/include/rtems/gxx_wrappers.h | 10 +--
cpukit/libcsupport/src/gxx_wrappers.c | 111 +++-
testsuites/libt
From: Christian Mauderer
The man-page for pthread_setspecific does not define the EAGAIN return value.
Further without this patch it was not possible to set keys that have been
already set a new value.
---
cpukit/posix/src/keysetspecific.c | 59 +++
1 file cha
From: Christian Mauderer
The rtems_gxx_key_dtor function is not longer used by gcc.
---
cpukit/libcsupport/include/rtems/gxx_wrappers.h | 2 --
cpukit/libcsupport/src/gxx_wrappers.c | 10 --
testsuites/libtests/gxx01/gxx01.doc | 1 -
testsuites/libtests/gxx01/gxx0
Hi,Philipp:
I think it's my responsibility to fix this bug. And it's a good opportunity
to know the change of RTEMS.
However, I can begin to do it only in weekend due to some course at
college. :-(
---
Best Regards.
Youren Shen.
On Fri, Mar 21, 2014 at 4:53 PM, Philipp Eppelt <
philipp.epp...@ma
Hi Youren,
git apply $attached_patch$
I have a meeting to attend to, so I don't have the time to test it right
now; will do it later. I hope it works.
Cheers,
Philipp
On 03/21/2014 09:30 AM, Philipp Eppelt wrote:
> Hi Youren,
>
> I just looked at a fresh RTEMS clone. I thought the patch elimin
Hi Youren,
I just looked at a fresh RTEMS clone. I thought the patch eliminating
sensitive instructions from the x86 paravirt target was merged, but it
looks like it wasn't.
I am working on an up to date patch. The old one, doesn't work anymore.
Cheers,
Philipp
On 03/21/2014 03:27 AM, Youren Sh
30 matches
Mail list logo
