Re: reentrant sprintf causes segmentation fault

David - If you're going to use FreeRTOS or similar, this might prove 
helpful:
http://www.nadler.com/embedded/newlibAndFreeRTOS.html

On 5/3/2019 1:25 PM, David Lawrence wrote:
> Dear Craig,
>
> Thank you very much for the explanation and pointer to the manual.
> Indeed, the manual is quite clear on this topic and I'm embarrassed
> that I missed it on my first reading. Sorry to waste your time with
> this question :-)
>
> Best regards,
> David
>
> On Fri, May 3, 2019 at 1:18 PM Craig Howland <[email protected]> wrote:
>> On 5/3/19 12:43 PM, David Lawrence wrote:
>>> Dear newlib maintainers and friends,
>>>
>>> I am having some trouble with newlib on a bare-metal embedded system
>>> that makes reentrant calls to sprintf. The reentrant call reliably
>>> experiences a segmentation fault. I have tested with both newlib 2.4.0
>>> and newlib 3.0.0, with both newlib-nano and regular newlib, to no
>>> effect.
>>>
>>> ...
>>>
>>> Do I have a fundamental misunderstanding of newlib's capability to
>>> support reentrant calls? Or does this seem like a legitimate bug? I
>>> would appreciate any suggestions for workarounds, and I would be happy
>>> to provide additional information or perform any further tests to
>>> assist the maintainers with this possible issue.
>>>
>>> Best regards,
>>>
>>> David Lawrence
>> David:
>>        Reentrancy requires setup on your part, of which I see none in your
>> supplied fragments.  Generate the manual and look at the reentrancy section.
>> (You can also look at libc/reent/reent.tex, avoiding the need to make the manual
>> but then being in source with formatting commands.)  It describes the 2 methods
>> for handling it. In brief, you either need to directly call the reentrant forms
>> of the functions with a per-thread structure, or you need to "context switch" by
>> setting the global reentrancy pointer for each thread. (No, they do not need to
>> be proper threads, but it gets the point across easily to use that term as an
>> analogy.)  The second method is easier from the perspective of hiding reentrency
>> from the main body of application code.  Both cases require you to define at
>> least one of your own reentrancy structures in addition to the single default one.
>>        A simple technique I have used in an application quite like yours is to
>> have the interrupt handler save _impure_ptr, overwrite it with the ISR's own,
>> print, then restore _impure_ptr.
>>                   Craig

-- 
Dave Nadler, USA East Coast voice (978) 263-0097, [email protected], Skype
  Dave.Nadler1