On 14/9/2023 4:55 pm, Sebastian Huber wrote:
> On 14.09.23 08:34, Sebastian Huber wrote:
>> This seems to break the mips build:
>>
>> cpukit/libdl/rtl-tls.c:104:2: error: #error unsupported architecture
>> 104 | #error unsupported architecture
>> | ^
>>
>
> Also the moxie and 64-bit
Fix rtems_configuration_get_interrupt_stack_size() for some code models.
The _ISR_Stack_size symbol has an arbitrary absolute address and may not
be representable in the code model used by the compiler.
Update #4953.
---
cpukit/include/rtems/config.h| 2 +-
cpukit/include/rtems/score/isr.h
On 14.09.23 09:12, Chris Johns wrote:
On 14/9/2023 4:55 pm, Sebastian Huber wrote:
On 14.09.23 08:34, Sebastian Huber wrote:
This seems to break the mips build:
cpukit/libdl/rtl-tls.c:104:2: error: #error unsupported architecture
104 | #error unsupported architecture
| ^
Als
On 14/9/2023 5:20 pm, Sebastian Huber wrote:
> On 14.09.23 09:12, Chris Johns wrote:
>> On 14/9/2023 4:55 pm, Sebastian Huber wrote:
>>> On 14.09.23 08:34, Sebastian Huber wrote:
This seems to break the mips build:
cpukit/libdl/rtl-tls.c:104:2: error: #error unsupported architecture
On 14.09.23 09:38, Chris Johns wrote:
The issue I faced was no score interface to get the TLS base for a thread to
determine a symbol's offset. If we had that and something to say if TLS is
supported libdl would be easy to fix.
Why don't we add this interface if it simplifies things?
Yes please
On 14/9/2023 5:58 pm, Sebastian Huber wrote:
> On 14.09.23 09:38, Chris Johns wrote:
The issue I faced was no score interface to get the TLS base for a thread
to
determine a symbol's offset. If we had that and something to say if TLS is
supported libdl would be easy to fix.
>>>
On 14.09.23 10:51, Chris Johns wrote:
On 14/9/2023 5:58 pm, Sebastian Huber wrote:
On 14.09.23 09:38, Chris Johns wrote:
The issue I faced was no score interface to get the TLS base for a thread to
determine a symbol's offset. If we had that and something to say if TLS is
supported libdl woul
Hello Kevin,
On 18.08.23 14:37, EYSSARTIER Kevin wrote:
Classified as: {OPEN}
Hello Sebastian,
The level shall be zero. If it is non-zero, then this is an application
bug resulting in the INTERNAL_ERROR_BAD_THREAD_DISPATCH_ENVIRONMENT
fatal error. This error happens also if you call op
On Thu, Sep 14, 2023 at 4:33 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
>
>
> On 14.09.23 10:51, Chris Johns wrote:
> > On 14/9/2023 5:58 pm, Sebastian Huber wrote:
> >> On 14.09.23 09:38, Chris Johns wrote:
> > The issue I faced was no score interface to get the TLS base
Thanks, I left comments on your pull request.
On Wed, Sep 6, 2023 at 7:26 AM andrew.butterfi...@scss.tcd.ie
wrote:
>
> Ping
>
> (I've let this sit a while - time to wake it up!)
>
>
> Andrew Butterfield Tel: +353-1-896-2517 Fax
Hello Peter,
Am 13.09.23 um 19:22 schrieb Peter Dufault:
On Jul 25, 2023, at 10:14 , Joel Sherrill wrote:
Most of those are recent and from a lot of different people. GSoC, Kinsey,
you, Vijay or Chris, Karel, etc. But I wonder about that phycore_mpc5554. I
think it has been around a LONG ti
Hello Peter,
just my two cents regarding eTPU: NXP has more or less left the PowerPC
architecture and favor ARM for automotive applications.
But the MPC5xxx controllers were developed in some sort of cooperation
with ST microelectronics. And ST is still actively playing with this
family. E.g
Hello Thomas,
On 9/14/23 21:35, Thomas DOERFLER wrote:
Hello Peter,
just my two cents regarding eTPU: NXP has more or less left the PowerPC
architecture and favor ARM for automotive applications.
But the MPC5xxx controllers were developed in some sort of cooperation
with ST microelectro
On 14/9/2023 7:33 pm, Sebastian Huber wrote:
> On 14.09.23 10:51, Chris Johns wrote:
>> On 14/9/2023 5:58 pm, Sebastian Huber wrote:
>>> On 14.09.23 09:38, Chris Johns wrote:
>> The issue I faced was no score interface to get the TLS base for a
>> thread to
>> determine a symbol's offs
14 matches
Mail list logo
