Re: reentrant sprintf causes segmentation fault

[Joel Sherrill <joel at rtems dot org>]

Since FreeRTOS was mention, I will throw out that for RTEMS, the
reentrancy structure is completely managed for you and there are
no oddities. Works fine even in SMP configurations. This is all integrated
into the standard source.

--joel

On Fri, May 3, 2019 at 12:43 PM Dave Nadler <drn@nadler.com> wrote:

> 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 <howland@lgsinnovations.com>
> 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, drn@nadler.com, Skype
>   Dave.Nadler1
>
>