portugalfuturista/universalisos
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

feat(docs): extract all extractable PikeOS PDF manuals to markdown

Browse source 
- Extract 37 of 45 PDFs under docs/ to docs-extracted/
- Preserve directory structure (apex, cdk, development, platform, etc.)
- Add docs-extracted/index.md with navigation table
- 8 PDFs were 0-byte/empty and could not be extracted
This commit is contained in:
Fábio Coutada 2026-07-06 23:07:19 +01:00
parent aa516bded6
commit ae6144a1c5
38 changed files with 165899 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

17343
docs-extracted/cdk/as-user-manual.md Normal file
View file

File diff suppressed because it is too large Load diff

3885
docs-extracted/cdk/binutils-user-manual.md Normal file
View file

File diff suppressed because it is too large Load diff

3673
docs-extracted/cdk/cpp-preprocessor-user-manual.md Normal file
View file

File diff suppressed because it is too large Load diff

734
docs-extracted/cdk/cpplib-internals.md Normal file
View file

@ -0,0 +1,734 @@
---
title: "Cpplib Internals"
source: "docs/cdk/cpplib-internals.pdf"
category: "cdk"
pages: 28
extracted: "2026-07-06T23:05:24.245582"
---
# Cpplib Internals
> Extracted from `docs/cdk/cpplib-internals.pdf` (28 pages).
> Figures, diagrams, and tables may not render accurately in plain text.
Cpplib Internals
For gcc version 7.4.0
(GCC)
Neil Booth
Copyright c 2000-2017 Free Software Foundation, Inc.
Permission is granted to make and distribute verbatim copies of this manual provided the
copyright notice and this permission notice are preserved on all copies.
Permission is granted to copy and distribute modified versions of this manual under the
conditions for verbatim copying, provided also that the entire resulting derived work is
distributed under the terms of a permission notice identical to this one.
Permission is granted to copy and distribute translations of this manual into another lan-
guage, under the above conditions for modified versions.
i
Table of Contents
Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
The Lexer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Lexing a token . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Lexing a line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Hash Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Macro Expansion Algorithm . . . . . . . . . . . . . . . . . . . . . 11
Internal representation of macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Macro expansion overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Scanning the replacement list for macros to expand . . . . . . . . . . . . . . . . . 12
Looking for a function-like macro’s opening parenthesis . . . . . . . . . . . . . 13
Marking tokens ineligible for future expansion . . . . . . . . . . . . . . . . . . . . . . 13
Token Spacing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Line numbering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Just which line number anyway? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Representation of line numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
The Multiple-Include Optimization . . . . . . . . . . . . . . 19
File Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Concept Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Conventions 1
Conventions
cpplib has two interfaces—one is exposed internally only, and the other is for both internal
and external use.
The convention is that functions and types that are exposed to multiple files internally
are prefixed with ‘_cpp_’, and are to be found in the file ‘internal.h’. Functions and
types exposed to external clients are in ‘cpplib.h’, and prefixed with ‘cpp_’. For historical
reasons this is no longer quite true, but we should strive to stick to it.
We are striving to reduce the information exposed in ‘cpplib.h’ to the bare minimum
necessary, and then to keep it there. This makes clear exactly what external clients are
entitled to assume, and allows us to change internals in the future without worrying whether
library clients are perhaps relying on some kind of undocumented implementation-specific
behavior.
The Lexer 3
The Lexer
Overview
The lexer is contained in the file ‘lex.c’. It is a hand-coded lexer, and not implemented
as a state machine. It can understand C, C++ and Objective-C source code, and has been
extended to allow reasonably successful preprocessing of assembly language. The lexer does
not make an initial pass to strip out trigraphs and escaped newlines, but handles them
as they are encountered in a single pass of the input file. It returns preprocessing tokens
individually, not a line at a time.
It is mostly transparent to users of the library, since the library’s interface for obtaining
the next token, cpp_get_token, takes care of lexing new tokens, handling directives, and
expanding macros as necessary. However, the lexer does expose some functionality so that
clients of the library can easily spell a given token, such as cpp_spell_token and cpp_
token_len. These functions are useful when generating diagnostics, and for emitting the
preprocessed output.
Lexing a token
Lexing of an individual token is handled by _cpp_lex_direct and its subroutines. In its
current form the code is quite complicated, with read ahead characters and such-like, since
it strives to not step back in the character stream in preparation for handling non-ASCII
file encodings. The current plan is to convert any such files to UTF-8 before processing
them. This complexity is therefore unnecessary and will be removed, so I’ll not discuss it
further here.
The job of _cpp_lex_direct is simply to lex a token. It is not responsible for issues like
directive handling, returning lookahead tokens directly, multiple-include optimization, or
conditional block skipping. It necessarily has a minor r^ole to play in memory management
of lexed lines. I discuss these issues in a separate section (see [Lexing a line], page 5).
The lexer places the token it lexes into storage pointed to by the variable cur_token,
and then increments it. This variable is important for correct diagnostic positioning. Unless
a specific line and column are passed to the diagnostic routines, they will examine the line
and col values of the token just before the location that cur_token points to, and use that
location to report the diagnostic.
The lexer does not consider whitespace to be a token in its own right. If whitespace
(other than a new line) precedes a token, it sets the PREV_WHITE bit in the token’s flags.
Each token has its line and col variables set to the line and column of the first character of
the token. This line number is the line number in the translation unit, and can be converted
to a source (file, line) pair using the line map code.
The first token on a logical, i.e. unescaped, line has the flag BOL set for beginning-of-line.
This flag is intended for internal use, both to distinguish a ‘#’ that begins a directive from
one that doesn’t, and to generate a call-back to clients that want to be notified about the
start of every non-directive line with tokens on it. Clients cannot reliably determine this
for themselves: the first token might be a macro, and the tokens of a macro expansion do
not have the BOL flag set. The macro expansion may even be empty, and the next token on
the line certainly won’t have the BOL flag set.
4 The GNU C Preprocessor Internals
New lines are treated specially; exactly how the lexer handles them is context-dependent.
The C standard mandates that directives are terminated by the first unescaped newline
character, even if it appears in the middle of a macro expansion. Therefore, if the state
variable in_directive is set, the lexer returns a CPP_EOF token, which is normally used to
indicate end-of-file, to indicate end-of-directive. In a directive a CPP_EOF token never means
end-of-file. Conveniently, if the caller was collect_args, it already handles CPP_EOF as if
it were end-of-file, and reports an error about an unterminated macro argument list.
The C standard also specifies that a new line in the middle of the arguments to a macro
is treated as whitespace. This white space is important in case the macro argument is
stringized. The state variable parsing_args is nonzero when the preprocessor is collecting
the arguments to a macro call. It is set to 1 when looking for the opening parenthesis
to a function-like macro, and 2 when collecting the actual arguments up to the closing
parenthesis, since these two cases need to be distinguished sometimes. One such time is
here: the lexer sets the PREV_WHITE flag of a token if it meets a new line when parsing_
args is set to 2. It doesn’t set it if it meets a new line when parsing_args is 1, since then
code like
#define foo() bar
foo
baz
would be output with an erroneous space before ‘baz’:
foo
baz
This is a good example of the subtlety of getting token spacing correct in the preproces-
sor; there are plenty of tests in the testsuite for corner cases like this.
The lexer is written to treat each of ‘\r’, ‘\n’, ‘\r\n’ and ‘\n\r’ as a single new line
indicator. This allows it to transparently preprocess MS-DOS, Macintosh and Unix files
without their needing to pass through a special filter beforehand.
We also decided to treat a backslash, either ‘\’ or the trigraph ‘??/’, separated from one
of the above newline indicators by non-comment whitespace only, as intending to escape the
newline. It tends to be a typing mistake, and cannot reasonably be mistaken for anything
else in any of the C-family grammars. Since handling it this way is not strictly conforming
to the ISO standard, the library issues a warning wherever it encounters it.
Handling newlines like this is made simpler by doing it in one place only. The function
handle_newline takes care of all newline characters, and skip_escaped_newlines takes
care of arbitrarily long sequences of escaped newlines, deferring to handle_newline to
handle the newlines themselves.
The most painful aspect of lexing ISO-standard C and C++ is handling trigraphs and
backlash-escaped newlines. Trigraphs are processed before any interpretation of the meaning
of a character is made, and unfortunately there is a trigraph representation for a backslash,
so it is possible for the trigraph ‘??/’ to introduce an escaped newline.
Escaped newlines are tedious because theoretically they can occur anywhere—between
the ‘+’ and ‘=’ of the ‘+=’ token, within the characters of an identifier, and even between
the ‘*’ and ‘/’ that terminates a comment. Moreover, you cannot be sure there is just
one—there might be an arbitrarily long sequence of them.
So, for example, the routine that lexes a number, parse_number, cannot assume that it
can scan forwards until the first non-number character and be done with it, because this
The Lexer 5
could be the ‘\’ introducing an escaped newline, or the ‘?’ introducing the trigraph sequence
that represents the ‘\’ of an escaped newline. If it encounters a ‘?’ or ‘\’, it calls skip_
escaped_newlines to skip over any potential escaped newlines before checking whether the
number has been finished.
Similarly code in the main body of _cpp_lex_direct cannot simply check for a ‘=’ after
a ‘+’ character to determine whether it has a ‘+=’ token; it needs to be prepared for an
escaped newline of some sort. Such cases use the function get_effective_char, which
returns the first character after any intervening escaped newlines.
The lexer needs to keep track of the correct column position, including counting tabs as
specified by the ‘-ftabstop=’ option. This should be done even within C-style comments;
they can appear in the middle of a line, and we want to report diagnostics in the correct
position for text appearing after the end of the comment.
Some identifiers, such as __VA_ARGS__ and poisoned identifiers, may be invalid and re-
quire a diagnostic. However, if they appear in a macro expansion we don’t want to complain
with each use of the macro. It is therefore best to catch them during the lexing stage, in
parse_identifier. In both cases, whether a diagnostic is needed or not is dependent upon
the lexer’s state. For example, we don’t want to issue a diagnostic for re-poisoning a poi-
soned identifier, or for using __VA_ARGS__ in the expansion of a variable-argument macro.
Therefore parse_identifier makes use of state flags to determine whether a diagnostic
is appropriate. Since we change state on a per-token basis, and don’t lex whole lines at a
time, this is not a problem.
Another place where state flags are used to change behavior is whilst lexing header
names. Normally, a ‘<’ would be lexed as a single token. After a #include directive,
though, it should be lexed as a single token as far as the nearest ‘>’ character. Note that
we don’t allow the terminators of header names to be escaped; the first ‘"’ or ‘>’ terminates
the header name.
Interpretation of some character sequences depends upon whether we are lexing C, C++
or Objective-C, and on the revision of the standard in force. For example, ‘::’ is a single
token in C++, but in C it is two separate ‘:’ tokens and almost certainly a syntax error.
Such cases are handled by _cpp_lex_direct based upon command-line flags stored in the
cpp_options structure.
Once a token has been lexed, it leads an independent existence. The spelling of numbers,
identifiers and strings is copied to permanent storage from the original input buffer, so a
token remains valid and correct even if its source buffer is freed with _cpp_pop_buffer.
The storage holding the spellings of such tokens remains until the client program calls
cpp destroy, probably at the end of the translation unit.
Lexing a line
When the preprocessor was changed to return pointers to tokens, one feature I wanted
was some sort of guarantee regarding how long a returned pointer remains valid. This is
important to the stand-alone preprocessor, the future direction of the C family front ends,
and even to cpplib itself internally.
Occasionally the preprocessor wants to be able to peek ahead in the token stream. For
example, after the name of a function-like macro, it wants to check the next token to see
if it is an opening parenthesis. Another example is that, after reading the first few tokens
6 The GNU C Preprocessor Internals
of a #pragma directive and not recognizing it as a registered pragma, it wants to backtrack
and allow the user-defined handler for unknown pragmas to access the full #pragma token
stream. The stand-alone preprocessor wants to be able to test the current token with the
previous one to see if a space needs to be inserted to preserve their separate tokenization
upon re-lexing (paste avoidance), so it needs to be sure the pointer to the previous token is
still valid. The recursive-descent C++ parser wants to be able to perform tentative parsing
arbitrarily far ahead in the token stream, and then to be able to jump back to a prior
position in that stream if necessary.
The rule I chose, which is fairly natural, is to arrange that the preprocessor lex all tokens
on a line consecutively into a token buffer, which I call a token run, and when meeting an
unescaped new line (newlines within comments do not count either), to start lexing back
at the beginning of the run. Note that we do not lex a line of tokens at once; if we did that
parse_identifier would not have state flags available to warn about invalid identifiers
(see [Invalid identifiers], page 5).
In other words, accessing tokens that appeared earlier in the current line is valid, but
since each logical line overwrites the tokens of the previous line, tokens from prior lines are
unavailable. In particular, since a directive only occupies a single logical line, this means
that the directive handlers like the #pragma handler can jump around in the directive’s
tokens if necessary.
Two issues remain: what about tokens that arise from macro expansions, and what
happens when we have a long line that overflows the token run?
Since we promise clients that we preserve the validity of pointers that we have already
returned for tokens that appeared earlier in the line, we cannot reallocate the run. Instead,
on overflow it is expanded by chaining a new token run on to the end of the existing one.
The tokens forming a macro’s replacement list are collected by the #define handler, and
placed in storage that is only freed by cpp_destroy. So if a macro is expanded in the line
of tokens, the pointers to the tokens of its expansion that are returned will always remain
valid. However, macros are a little trickier than that, since they give rise to three sources of
fresh tokens. They are the built-in macros like __LINE__, and the ‘#’ and ‘##’ operators for
stringizing and token pasting. I handled this by allocating space for these tokens from the
lexer’s token run chain. This means they automatically receive the same lifetime guarantees
as lexed tokens, and we don’t need to concern ourselves with freeing them.
Lexing into a line of tokens solves some of the token memory management issues, but
not all. The opening parenthesis after a function-like macro name might lie on a different
line, and the front ends definitely want the ability to look ahead past the end of the current
line. So cpplib only moves back to the start of the token run at the end of a line if the
variable keep_tokens is zero. Line-buffering is quite natural for the preprocessor, and as a
result the only time cpplib needs to increment this variable is whilst looking for the opening
parenthesis to, and reading the arguments of, a function-like macro. In the near future
cpplib will export an interface to increment and decrement this variable, so that clients can
share full control over the lifetime of token pointers too.
The routine _cpp_lex_token handles moving to new token runs, calling _cpp_lex_
direct to lex new tokens, or returning previously-lexed tokens if we stepped back in the
token stream. It also checks each token for the BOL flag, which might indicate a directive that
needs to be handled, or require a start-of-line call-back to be made. _cpp_lex_token also
The Lexer 7
handles skipping over tokens in failed conditional blocks, and invalidates the control macro
of the multiple-include optimization if a token was successfully lexed outside a directive. In
other words, its callers do not need to concern themselves with such issues.
Hash Nodes 9
Hash Nodes
When cpplib encounters an “identifier”, it generates a hash code for it and stores it in the
hash table. By “identifier” we mean tokens with type CPP_NAME; this includes identifiers
in the usual C sense, as well as keywords, directive names, macro names and so on. For
example, all of pragma, int, foo and __GNUC__ are identifiers and hashed when lexed.
Each node in the hash table contain various information about the identifier it represents.
For example, its length and type. At any one time, each identifier falls into exactly one of
three categories:
• Macros
These have been declared to be macros, either on the command line or with #define.
A few, such as __TIME__ are built-ins entered in the hash table during initialization.
The hash node for a normal macro points to a structure with more information about
the macro, such as whether it is function-like, how many arguments it takes, and
its expansion. Built-in macros are flagged as special, and instead contain an enum
indicating which of the various built-in macros it is.
• Assertions
Assertions are in a separate namespace to macros. To enforce this, cpp actually
prepends a # character before hashing and entering it in the hash table. An asser-
tion’s node points to a chain of answers to that assertion.
• Void
Everything else falls into this category—an identifier that is not currently a macro, or
a macro that has since been undefined with #undef.
When preprocessing C++, this category also includes the named operators, such as xor.
In expressions these behave like the operators they represent, but in contexts where
the spelling of a token matters they are spelt differently. This spelling distinction is
relevant when they are operands of the stringizing and pasting macro operators # and
##. Named operator hash nodes are flagged, both to catch the spelling distinction and
to prevent them from being defined as macros.
The same identifiers share the same hash node. Since each identifier token, after lexing,
contains a pointer to its hash node, this is used to provide rapid lookup of various informa-
tion. For example, when parsing a #define statement, CPP flags each argument’s identifier
hash node with the index of that argument. This makes duplicated argument checking an
O(1) operation for each argument. Similarly, for each identifier in the macro’s expansion,
lookup to see if it is an argument, and which argument it is, is also an O(1) operation.
Further, each directive name, such as endif, has an associated directive enum stored in its
hash node, so that directive lookup is also O(1).
Macro Expansion Algorithm 11
Macro Expansion Algorithm
Macro expansion is a tricky operation, fraught with nasty corner cases and situations that
render what you thought was a nifty way to optimize the preprocessor’s expansion algorithm
wrong in quite subtle ways.
I strongly recommend you have a good grasp of how the C and C++ standards require
macros to be expanded before diving into this section, let alone the code!. If you don’t have
a clear mental picture of how things like nested macro expansion, stringizing and token
pasting are supposed to work, damage to your sanity can quickly result.
Internal representation of macros
The preprocessor stores macro expansions in tokenized form. This saves repeated lexing
passes during expansion, at the cost of a small increase in memory consumption on average.
The tokens are stored contiguously in memory, so a pointer to the first one and a token
count is all you need to get the replacement list of a macro.
If the macro is a function-like macro the preprocessor also stores its parameters, in the
form of an ordered list of pointers to the hash table entry of each parameter’s identifier.
Further, in the macro’s stored expansion each occurrence of a parameter is replaced with a
special token of type CPP_MACRO_ARG. Each such token holds the index of the parameter it
represents in the parameter list, which allows rapid replacement of parameters with their
arguments during expansion. Despite this optimization it is still necessary to store the
original parameters to the macro, both for dumping with e.g., ‘-dD’, and to warn about
non-trivial macro redefinitions when the parameter names have changed.
Macro expansion overview
The preprocessor maintains a context stack, implemented as a linked list of cpp_context
structures, which together represent the macro expansion state at any one time. The
struct cpp_reader member variable context points to the current top of this stack. The
top normally holds the unexpanded replacement list of the innermost macro under expan-
sion, except when cpplib is about to pre-expand an argument, in which case it holds that
argument’s unexpanded tokens.
When there are no macros under expansion, cpplib is in base context. All contexts
other than the base context contain a contiguous list of tokens delimited by a starting and
ending token. When not in base context, cpplib obtains the next token from the list of the
top context. If there are no tokens left in the list, it pops that context off the stack, and
subsequent ones if necessary, until an unexhausted context is found or it returns to base
context. In base context, cpplib reads tokens directly from the lexer.
If it encounters an identifier that is both a macro and enabled for expansion, cpplib pre-
pares to push a new context for that macro on the stack by calling the routine enter_macro_
context. When this routine returns, the new context will contain the unexpanded tokens
of the replacement list of that macro. In the case of function-like macros, enter_macro_
context also replaces any parameters in the replacement list, stored as CPP_MACRO_ARG
tokens, with the appropriate macro argument. If the standard requires that the parameter
be replaced with its expanded argument, the argument will have been fully macro expanded
first.
12 The GNU C Preprocessor Internals
enter_macro_context also handles special macros like __LINE__. Although these
macros expand to a single token which cannot contain any further macros, for reasons
of token spacing (see [Token Spacing], page 15) and simplicity of implementation, cpplib
handles these special macros by pushing a context containing just that one token.
The final thing that enter_macro_context does before returning is to mark the macro
disabled for expansion (except for special macros like __TIME__). The macro is re-enabled
when its context is later popped from the context stack, as described above. This strict
ordering ensures that a macro is disabled whilst its expansion is being scanned, but that it
is not disabled whilst any arguments to it are being expanded.
Scanning the replacement list for macros to expand
The C standard states that, after any parameters have been replaced with their possibly-
expanded arguments, the replacement list is scanned for nested macros. Further, any iden-
tifiers in the replacement list that are not expanded during this scan are never again eligible
for expansion in the future, if the reason they were not expanded is that the macro in
question was disabled.
Clearly this latter condition can only apply to tokens resulting from argument pre-
expansion. Other tokens never have an opportunity to be re-tested for expansion. It is
possible for identifiers that are function-like macros to not expand initially but to expand
during a later scan. This occurs when the identifier is the last token of an argument (and
therefore originally followed by a comma or a closing parenthesis in its macro’s argument
list), and when it replaces its parameter in the macro’s replacement list, the subsequent
token happens to be an opening parenthesis (itself possibly the first token of an argument).
It is important to note that when cpplib reads the last token of a given context, that
context still remains on the stack. Only when looking for the next token do we pop it off
the stack and drop to a lower context. This makes backing up by one token easy, but more
importantly ensures that the macro corresponding to the current context is still disabled
when we are considering the last token of its replacement list for expansion (or indeed
expanding it). As an example, which illustrates many of the points above, consider
#define foo(x) bar x
foo(foo) (2)
which fully expands to ‘bar foo (2)’. During pre-expansion of the argument, ‘foo’ does
not expand even though the macro is enabled, since it has no following parenthesis [pre-
expansion of an argument only uses tokens from that argument; it cannot take tokens from
whatever follows the macro invocation]. This still leaves the argument token ‘foo’ eligible
for future expansion. Then, when re-scanning after argument replacement, the token ‘foo’
is rejected for expansion, and marked ineligible for future expansion, since the macro is now
disabled. It is disabled because the replacement list ‘bar foo’ of the macro is still on the
context stack.
If instead the algorithm looked for an opening parenthesis first and then tested whether
the macro were disabled it would be subtly wrong. In the example above, the replacement
list of ‘foo’ would be popped in the process of finding the parenthesis, re-enabling ‘foo’
and expanding it a second time.
Macro Expansion Algorithm 13
Looking for a function-like macro’s opening parenthesis
Function-like macros only expand when immediately followed by a parenthesis. To do
this cpplib needs to temporarily disable macros and read the next token. Unfortunately,
because of spacing issues (see [Token Spacing], page 15), there can be fake padding tokens
in-between, and if the next real token is not a parenthesis cpplib needs to be able to back
up that one token as well as retain the information in any intervening padding tokens.
Backing up more than one token when macros are involved is not permitted by cpplib,
because in general it might involve issues like restoring popped contexts onto the context
stack, which are too hard. Instead, searching for the parenthesis is handled by a special
function, funlike_invocation_p, which remembers padding information as it reads tokens.
If the next real token is not an opening parenthesis, it backs up that one token, and then
pushes an extra context just containing the padding information if necessary.
Marking tokens ineligible for future expansion
As discussed above, cpplib needs a way of marking tokens as unexpandable. Since the
tokens cpplib handles are read-only once they have been lexed, it instead makes a copy of
the token and adds the flag NO_EXPAND to the copy.
For efficiency and to simplify memory management by avoiding having to remember to
free these tokens, they are allocated as temporary tokens from the lexer’s current token
run (see [Lexing a line], page 5) using the function _cpp_temp_token. The tokens are then
re-used once the current line of tokens has been read in.
This might sound unsafe. However, tokens runs are not re-used at the end of a line if
it happens to be in the middle of a macro argument list, and cpplib only wants to back-
up more than one lexer token in situations where no macro expansion is involved, so the
optimization is safe.
Token Spacing 15
Token Spacing
First, consider an issue that only concerns the stand-alone preprocessor: there needs to be
a guarantee that re-reading its preprocessed output results in an identical token stream.
Without taking special measures, this might not be the case because of macro substitution.
For example:
#define PLUS +
#define EMPTY
#define f(x) =x=
+PLUS -EMPTY- PLUS+ f(=)
7→ + + - - + + = = =
not
7→ ++ -- ++ ===
One solution would be to simply insert a space between all adjacent tokens. However,
we would like to keep space insertion to a minimum, both for aesthetic reasons and because
it causes problems for people who still try to abuse the preprocessor for things like Fortran
source and Makefiles.
For now, just notice that when tokens are added (or removed, as shown by the EMPTY
example) from the original lexed token stream, we need to check for accidental token pasting.
We call this paste avoidance. Token addition and removal can only occur because of macro
expansion, but accidental pasting can occur in many places: both before and after each
macro replacement, each argument replacement, and additionally each token created by the
‘#’ and ‘##’ operators.
Look at how the preprocessor gets whitespace output correct normally. The cpp_token
structure contains a flags byte, and one of those flags is PREV_WHITE. This is flagged by the
lexer, and indicates that the token was preceded by whitespace of some form other than a
new line. The stand-alone preprocessor can use this flag to decide whether to insert a space
between tokens in the output.
Now consider the result of the following macro expansion:
#define add(x, y, z) x + y +z;
sum = add (1,2, 3);
7→ sum = 1 + 2 +3;
The interesting thing here is that the tokens ‘1’ and ‘2’ are output with a preceding
space, and ‘3’ is output without a preceding space, but when lexed none of these tokens had
that property. Careful consideration reveals that ‘1’ gets its preceding whitespace from the
space preceding ‘add’ in the macro invocation, not replacement list. ‘2’ gets its whitespace
from the space preceding the parameter ‘y’ in the macro replacement list, and ‘3’ has no
preceding space because parameter ‘z’ has none in the replacement list.
Once lexed, tokens are effectively fixed and cannot be altered, since pointers to them
might be held in many places, in particular by in-progress macro expansions. So instead
of modifying the two tokens above, the preprocessor inserts a special token, which I call
a padding token, into the token stream to indicate that spacing of the subsequent token
is special. The preprocessor inserts padding tokens in front of every macro expansion and
expanded macro argument. These point to a source token from which the subsequent real
token should inherit its spacing. In the above example, the source tokens are ‘add’ in the
macro invocation, and ‘y’ and ‘z’ in the macro replacement list, respectively.
16 The GNU C Preprocessor Internals
It is quite easy to get multiple padding tokens in a row, for example if a macro’s first
replacement token expands straight into another macro.
#define foo bar
#define bar baz
[foo]
7→ [baz]
Here, two padding tokens are generated with sources the ‘foo’ token between the brack-
ets, and the ‘bar’ token from foo’s replacement list, respectively. Clearly the first padding
token is the one to use, so the output code should contain a rule that the first padding
token in a sequence is the one that matters.
But what if a macro expansion is left? Adjusting the above example slightly:
#define foo bar
#define bar EMPTY baz
#define EMPTY
[foo] EMPTY;
7→ [ baz] ;
As shown, now there should be a space before ‘baz’ and the semicolon in the output.
The rules we decided above fail for ‘baz’: we generate three padding tokens, one per
macro invocation, before the token ‘baz’. We would then have it take its spacing from the
first of these, which carries source token ‘foo’ with no leading space.
It is vital that cpplib get spacing correct in these examples since any of these macro
expansions could be stringized, where spacing matters.
So, this demonstrates that not just entering macro and argument expansions, but leaving
them requires special handling too. I made cpplib insert a padding token with a NULL source
token when leaving macro expansions, as well as after each replaced argument in a macro’s
replacement list. It also inserts appropriate padding tokens on either side of tokens created
by the ‘#’ and ‘##’ operators. I expanded the rule so that, if we see a padding token with
a NULL source token, and that source token has no leading space, then we behave as if we
have seen no padding tokens at all. A quick check shows this rule will then get the above
example correct as well.
Now a relationship with paste avoidance is apparent: we have to be careful about paste
avoidance in exactly the same locations we have padding tokens in order to get white space
correct. This makes implementation of paste avoidance easy: wherever the stand-alone
preprocessor is fixing up spacing because of padding tokens, and it turns out that no space
is needed, it has to take the extra step to check that a space is not needed after all to avoid
an accidental paste. The function cpp_avoid_paste advises whether a space is required
between two consecutive tokens. To avoid excessive spacing, it tries hard to only require a
space if one is likely to be necessary, but for reasons of efficiency it is slightly conservative
and might recommend a space where one is not strictly needed.
Line numbering 17
Line numbering
Just which line number anyway?
There are three reasonable requirements a cpplib client might have for the line number of
a token passed to it:
• The source line it was lexed on.
• The line it is output on. This can be different to the line it was lexed on if, for example,
there are intervening escaped newlines or C-style comments. For example:
foo /* A long
comment */ bar \
baz
⇒
foo bar baz
• If the token results from a macro expansion, the line of the macro name, or possibly
the line of the closing parenthesis in the case of function-like macro expansion.
The cpp_token structure contains line and col members. The lexer fills these in
with the line and column of the first character of the token. Consequently, but maybe
unexpectedly, a token from the replacement list of a macro expansion carries the location
of the token within the #define directive, because cpplib expands a macro by returning
pointers to the tokens in its replacement list. The current implementation of cpplib assigns
tokens created from built-in macros and the ‘#’ and ‘##’ operators the location of the most
recently lexed token. This is a because they are allocated from the lexer’s token runs, and
because of the way the diagnostic routines infer the appropriate location to report.
The diagnostic routines in cpplib display the location of the most recently lexed token,
unless they are passed a specific line and column to report. For diagnostics regarding
tokens that arise from macro expansions, it might also be helpful for the user to see the
original location in the macro definition that the token came from. Since that is exactly
the information each token carries, such an enhancement could be made relatively easily in
future.
The stand-alone preprocessor faces a similar problem when determining the correct line
to output the token on: the position attached to a token is fairly useless if the token came
from a macro expansion. All tokens on a logical line should be output on its first physical
line, so the token’s reported location is also wrong if it is part of a physical line other than
the first.
To solve these issues, cpplib provides a callback that is generated whenever it lexes a
preprocessing token that starts a new logical line other than a directive. It passes this token
(which may be a CPP_EOF token indicating the end of the translation unit) to the callback
routine, which can then use the line and column of this token to produce correct output.
Representation of line numbers
As mentioned above, cpplib stores with each token the line number that it was lexed on.
In fact, this number is not the number of the line in the source file, but instead bears more
resemblance to the number of the line in the translation unit.
18 The GNU C Preprocessor Internals
The preprocessor maintains a monotonic increasing line count, which is incremented at
every new line character (and also at the end of any buffer that does not end in a new line).
Since a line number of zero is useful to indicate certain special states and conditions, this
variable starts counting from one.
This variable therefore uniquely enumerates each line in the translation unit. With some
simple infrastructure, it is straight forward to map from this to the original source file and
line number pair, saving space whenever line number information needs to be saved. The
code the implements this mapping lies in the files ‘line-map.c’ and ‘line-map.h’.
Command-line macros and assertions are implemented by pushing a buffer containing
the right hand side of an equivalent #define or #assert directive. Some built-in macros
are handled similarly. Since these are all processed before the first line of the main input
file, it will typically have an assigned line closer to twenty than to one.
The Multiple-Include Optimization 19
The Multiple-Include Optimization
Header files are often of the form
#ifndef FOO
#define FOO
...
#endif
to prevent the compiler from processing them more than once. The preprocessor notices
such header files, so that if the header file appears in a subsequent #include directive and
FOO is defined, then it is ignored and it doesn’t preprocess or even re-open the file a second
time. This is referred to as the multiple include optimization.
Under what circumstances is such an optimization valid? If the file were included a
second time, it can only be optimized away if that inclusion would result in no tokens to
return, and no relevant directives to process. Therefore the current implementation imposes
requirements and makes some allowances as follows:
1. There must be no tokens outside the controlling #if-#endif pair, but whitespace and
comments are permitted.
2. There must be no directives outside the controlling directive pair, but the null directive
(a line containing nothing other than a single ‘#’ and possibly whitespace) is permitted.
3. The opening directive must be of the form
#ifndef FOO
or
#if !defined FOO [equivalently, #if !defined(FOO)]
4. In the second form above, the tokens forming the #if expression must have come
directly from the source file—no macro expansion must have been involved. This is
because macro definitions can change, and tracking whether or not a relevant change
has been made is not worth the implementation cost.
5. There can be no #else or #elif directives at the outer conditional block level, because
they would probably contain something of interest to a subsequent pass.
First, when pushing a new file on the buffer stack, _stack_include_file sets the con-
trolling macro mi_cmacro to NULL, and sets mi_valid to true. This indicates that the
preprocessor has not yet encountered anything that would invalidate the multiple-include
optimization. As described in the next few paragraphs, these two variables having these
values effectively indicates top-of-file.
When about to return a token that is not part of a directive, _cpp_lex_token sets mi_
valid to false. This enforces the constraint that tokens outside the controlling conditional
block invalidate the optimization.
The do_if, when appropriate, and do_ifndef directive handlers pass the controlling
macro to the function push_conditional. cpplib maintains a stack of nested conditional
blocks, and after processing every opening conditional this function pushes an if_stack
structure onto the stack. In this structure it records the controlling macro for the block,
provided there is one and we’re at top-of-file (as described above). If an #elif or #else
directive is encountered, the controlling macro for that block is cleared to NULL. Otherwise,
it survives until the #endif closing the block, upon which do_endif sets mi_valid to true
and stores the controlling macro in mi_cmacro.
20 The GNU C Preprocessor Internals
_cpp_handle_directive clears mi_valid when processing any directive other than an
opening conditional and the null directive. With this, and requiring top-of-file to record a
controlling macro, and no #else or #elif for it to survive and be copied to mi_cmacro by
do_endif, we have enforced the absence of directives outside the main conditional block for
the optimization to be on.
Note that whilst we are inside the conditional block, mi_valid is likely to be reset to
false, but this does not matter since the closing #endif restores it to true if appropriate.
Finally, since _cpp_lex_direct pops the file off the buffer stack at EOF without returning
a token, if the #endif directive was not followed by any tokens, mi_valid is true and _cpp_
pop_file_buffer remembers the controlling macro associated with the file. Subsequent
calls to stack_include_file result in no buffer being pushed if the controlling macro is
defined, effecting the optimization.
A quick word on how we handle the
#if !defined FOO
case. _cpp_parse_expr and parse_defined take steps to see whether the three stages ‘!’,
‘defined-expression’ and ‘end-of-directive’ occur in order in a #if expression. If so,
they return the guard macro to do_if in the variable mi_ind_cmacro, and otherwise set it
to NULL. enter_macro_context sets mi_valid to false, so if a macro was expanded whilst
parsing any part of the expression, then the top-of-file test in push_conditional fails and
the optimization is turned off.
File Handling 21
File Handling
Fairly obviously, the file handling code of cpplib resides in the file ‘files.c’. It takes care
of the details of file searching, opening, reading and caching, for both the main source file
and all the headers it recursively includes.
The basic strategy is to minimize the number of system calls. On many systems, the
basic open () and fstat () system calls can be quite expensive. For every #include-d file,
we need to try all the directories in the search path until we find a match. Some projects,
such as glibc, pass twenty or thirty include paths on the command line, so this can rapidly
become time consuming.
For a header file we have not encountered before we have little choice but to do this.
However, it is often the case that the same headers are repeatedly included, and in these
cases we try to avoid repeating the filesystem queries whilst searching for the correct file.
For each file we try to open, we store the constructed path in a splay tree. This path
first undergoes simplification by the function _cpp_simplify_pathname. For example,
‘/usr/include/bits/../foo.h’ is simplified to ‘/usr/include/foo.h’ before we enter it
in the splay tree and try to open () the file. CPP will then find subsequent uses of ‘foo.h’,
even as ‘/usr/include/foo.h’, in the splay tree and save system calls.
Further, it is likely the file contents have also been cached, saving a read () system call.
We don’t bother caching the contents of header files that are re-inclusion protected, and
whose re-inclusion macro is defined when we leave the header file for the first time. If the
host supports it, we try to map suitably large files into memory, rather than reading them
in directly.
The include paths are internally stored on a null-terminated singly-linked list, starting
with the "header.h" directory search chain, which then links into the <header.h> directory
chain.
Files included with the <foo.h> syntax start the lookup directly in the second half of
this chain. However, files included with the "foo.h" syntax start at the beginning of the
chain, but with one extra directory prepended. This is the directory of the current file;
the one containing the #include directive. Prepending this directory on a per-file basis is
handled by the function search_from.
Note that a header included with a directory component, such as #include
"mydir/foo.h" and opened as ‘/usr/local/include/mydir/foo.h’, will have the
complete path minus the basename ‘foo.h’ as the current directory.
Enough information is stored in the splay tree that CPP can immediately tell whether
it can skip the header file because of the multiple include optimization, whether the file
didn’t exist or couldn’t be opened for some reason, or whether the header was flagged not
to be re-used, as it is with the obsolete #import directive.
For the benefit of MS-DOS filesystems with an 8.3 filename limitation, CPP offers the
ability to treat various include file names as aliases for the real header files with shorter
names. The map from one to the other is found in a special file called ‘header.gcc’, stored
in the command line (or system) include directories to which the mapping applies. This
may be higher up the directory tree than the full path to the file minus the base name.
Concept Index 23
Concept Index
A L
assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 lexer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
line numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
C
controlling macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 M
macro expansion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
macro representation (internal) . . . . . . . . . . . . . . . . 11
E macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
escaped newlines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 multiple-include optimization . . . . . . . . . . . . . . . . . . 19
F N
files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 named operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
newlines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
G
guard macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 P
paste avoidance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
H
hash table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 S
header files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 spacing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
I T
identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 token run . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 token spacing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3312
docs-extracted/cdk/gcc-installation-manual.md Normal file
View file

File diff suppressed because it is too large Load diff

6303
docs-extracted/cdk/ld-user-manual.md Normal file
View file

File diff suppressed because it is too large Load diff

3090
docs-extracted/development/anis-reference-manual.md Normal file
View file

File diff suppressed because it is too large Load diff

3189
docs-extracted/development/cfs-reference-manual.md Normal file
View file

File diff suppressed because it is too large Load diff

2891
docs-extracted/development/instrumentation-monitoring-reference-manual.md Normal file
View file

File diff suppressed because it is too large Load diff

26887
docs-extracted/development/kernel-reference-manual.md Normal file
View file

File diff suppressed because it is too large Load diff

885
docs-extracted/development/libstand-reference-manual.md Normal file
View file

@ -0,0 +1,885 @@
---
title: "Libstand Reference Manual"
source: "docs/development/libstand-reference-manual.pdf"
category: "development"
pages: 34
extracted: "2026-07-06T23:05:34.816610"
---
# Libstand Reference Manual
> Extracted from `docs/development/libstand-reference-manual.pdf` (34 pages).
> Figures, diagrams, and tables may not render accurately in plain text.
PikeOS Standalone Utility Library
Reference Manual
Am Pfaffenstein 14, D-55270 Klein-Winternheim
Notice: The contents of this document are proprietary to
SYSGO GmbH and shall not be disclosed, disseminated,
copied, or used except for purposes expressly
authorized in writing by SYSGO GmbH.
Standalone Utility Library Reference Manual
PikeOS D5.0, Document Version D5.0-35
c 2005 – 2019 SYSGO GmbH
SYSGO GmbH Email: office@sysgo.com
Am Pfaffenstein 14
55270 Klein-Winternheim, Germany http://www.sysgo.com
All rights reserved.
PikeOS is a trademark of SYSGO GmbH. The designations used to identify other software or hardware products
in this publication may be trademarks of their manufacturers or sellers.
Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Libstand API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1 ANSI C standard I/O functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1 Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.1.1 sprintf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.1.2 vsprintf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.1.3 snprintf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.1.4 vsnprintf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2 ANSI C standard library functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.1 Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.1.1 strtoul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.1.2 strtol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.1.3 strtoull . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.1.4 strtoll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.1.5 bsearch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3 ANSI C string manipulation functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3.1 Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3.1.1 strncat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3.1.2 strncmp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3.1.3 strcmp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.3.1.4 strncpy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.3.1.5 strlen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.3.1.6 strnchr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.3.1.7 strnrchr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.3.1.8 strnlen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.3.1.9 strlcpy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.3.1.10 strlcat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.3.1.11 memset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.3.1.12 memchr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.3.1.13 memcpy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.3.1.14 memmove . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.3.1.15 memcmp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.4 ANSI C standard types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.4.1 Defines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.5 Assert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.5.1 Defines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
1 Introduction
The Standalone Utility Library (libstand) is available for all PikeOS personalities and PSPs. It contains several
useful functions from the ANSI C libraries for string formating, string to number conversions and string manipula-
tion.
To use it you need to include the header files(s) in your application. No further action is necessary. The available
header files are listed below.
Header File Functions
stand/stdio.h sprintf(), snprintf(), ...
stand/stdlib.h strtoul(), strtol(), ...
stand/string.h strcmp(), strcpy(), ...
stand/types.h LONG_MIN, LONG_MAX, ...
stand/assert.h assert() macro, ...
Note: The functions do not use the errno variable.
Note: The functions from stand/stdio.h are not available for PSPs.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
2 Libstand API
2.1 ANSI C standard I/O functions
This section describes the subset of the ANSI C standard I/O (stdio) functions included in libstand.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
6 Libstand API
2.1.1 Functions
2.1.1.1 sprintf
A function to format and print a string (fmt) to an out string (str).
Synopsis:
int sprintf(char *str,
const char *fmt,
...)
Parameters:
str OUT: Output string.
fmt IN: Format string.
Description:
See snprintf for a description of the supported format.
Returns:
This function returns the number of characters copied to the out string (not including the trailing NUL used to end
output to strings).
The return value is only sound if less that 2GB of characters are printed, otherwise int will overflow. There is no
overflow protection against this.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
ANSI C standard I/O functions 7
2.1.1.2 vsprintf
A function called with a va_list to format a string and print this formated string (fmt) to an out string (str).
Synopsis:
int vsprintf(char *str,
const char *fmt,
va_list ap)
Parameters:
str OUT: Output string.
fmt IN: Format string.
ap IN: Argument vector of format string.
Description:
See snprintf for a description of the supported format.
Returns:
This function returns the number of characters copied to the out string (not including the trailing NUL used to end
output to strings).
The return value is only sound if less that 2GB of characters are printed, otherwise int will overflow. There is no
overflow protection against this.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
8 Libstand API
2.1.1.3 snprintf
A function to format and print a string (fmt) to an out string (str), limited to a given amount of characters (size).
Synopsis:
int snprintf(char *str,
size_t size,
const char *fmt,
...)
Parameters:
str OUT: Output string.
size IN: Maximum number of chars.
fmt IN: Format string.
Description:
This function generally uses the well-known C language standard print format, but only a subset is supported. The
following options are supported.
Format tags begin with a ’%’ character and are followed by an optional sequence of flags, an optional field width,
an optional precision, an optional type size specification, and a mandatory conversion specifier.
Supported flags:
’+’ (plus) if the number is positive use a ’+’ character in front of the number.
’ ’ (space) if the number is positive, use a white space in front of the number.
’-’ (minus) left justify within field width (otherwise: right justify). A negative field width also triggers this option.
’0’ (zero) left fill with zeros to field width (otherwise: white space).
’#’ (hash) use alternative syntax; semantics depends on conversion specifier
Field width:
A decimal number using ’0’..’9’ characters: minimum number of characters to use in output string.
’*’ (asterisk): the field width is provided by an ’int’ argument.
Precision:
This always starts with a ’.’ (period) followed by:
A decimal number using ’0’..’9’ characters: precision to use for formatting. The exact sematics depends on the
conversion specifier.
’*’ (asterisk): the precision is provided by an ’int’ argument.
Type size:
’hh’: an integer the same size as ’char’
’h’: an integer the same size as ’short’
’l’: an integer the same size as ’long’
’ll’: an integer the same size as ’long long’
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
ANSI C standard I/O functions 9
’z’: an integer the same size as ’size_t’ (or ’P4_size_t’)
’t’: an integer the same size as ’ptrdiff_t’
Format specifiers:
’c’: a single character: ’#’ and precision are ignored.
’s’: a string: ’#’ is ignored. precision is the maximum number of characters at the beginning of the string to be
formatted.
’d’, ’i’: decimal signed integer. ’#’ is ignored. the precision is the minimum number of zeros printed; default
precision is 0.
’u’: decimal unsigned integer. ’#’ and precision works like with ’d’.
’x’: hexadecimal integer. ’#’ will cause printing ’0x’ prefix if the number is not 0. Precision works like with ’d’.
’X’: same as ’x’, but uses upper case characters.
’o’: octal integer. ’#’ will cause printing ’0’ prefix if number is not 0. Precision works like with ’d’.
’p’: prints void* pointer. Works like ’x’, but with a pointer argument interpreted as integer.
’P’: same as ’p’, but uses upper case characters.
Returns:
This function returns the number of characters copied to the out string (not including the trailing NUL used to
end output to strings). If more characters would be written than the limit given by (size), the function returns the
number of characters that would be written if no limit would exist.
The return value is only sound if less that 2GB of characters are printed, otherwise int will overflow. There is no
overflow protection against this.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
10 Libstand API
2.1.1.4 vsnprintf
A function called with a va_list to format a string and print this formated string (fmt) to an out string (str), limited to
a given number of characters (size).
Synopsis:
int vsnprintf(char *str,
size_t size,
const char *fmt,
va_list ap)
Parameters:
str OUT: Output string.
size IN: Maximum number of chars.
fmt IN: Format string.
ap IN: Argument vector of format string.
Description:
See snprintf for a description of the supported format.
Returns:
This function returns the number of characters copied to the out string (not including the trailing NUL used to
end output to strings). If more characters would be written than the limit given by (size), the function returns the
number of characters that would be written if no limit would exist.
The return value is only sound if less that 2GB of characters are printed, otherwise int will overflow. There is no
overflow protection against this.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
ANSI C standard library functions 11
2.2 ANSI C standard library functions
This section describes the subset of the ANSI C standard library (stdlib) functions included in libstand.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
12 Libstand API
2.2.1 Functions
2.2.1.1 strtoul
A function to parse an unsigned number from a string and return it as a number.
Synopsis:
unsigned long strtoul(const char *nptr,
char **endptr,
int base)
Parameters:
nptr IN: The string containing the number to be parsed
endptr OUT: The pointer to the first character after the parsed number.
base IN: The base of the number (2..36) or 0.
Description:
At the beginning of the string, ASCII white-space characters, i.e., SPACE or TAB, will be skipped first. Then, any
number of + and - will be parsed to possibly return a negated value. Then, if the base is 0 or 16, a prefix of 0x or
0X will be skipped.
Then, any number of valid digits for the given base will be parsed. Digits are 0..9,a..z, in that order. Digits a..z
have values 10..35. The case of the letters is insignificant; upper case and lower case digits are treated the same.
Bases of 2 through 36 are valid, and 0 means ’autodetect’, which means 10 by default, unless the potential number
starts with 0x or 0X, which means base 16 will be assumed, or unless the potential number starts with 0, in which
case base 8 will be assumed. If the base is outside 0,2,3..36, no digit will be parsed.
Digits are valid if their value is strictly smaller than the assumed base.
If endptr is NULL, *endptr will not be written.
Returns:
The parsed unsigned number.
*endptr is set to point to the first non-valid digit.
If converting the string to a number causes an overflow or underflow, (unsigned long)-1 is returned, and *endptr is
set equal to nptr.
If not a single digit could be parsed, 0 is returned and *endptr is set equal to nptr.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
ANSI C standard library functions 13
2.2.1.2 strtol
A function to parse a signed number from a string and return it as a number. The behaviour is just like strtoul, but
for signed numbers.
Synopsis:
long strtol(const char *nptr,
char **endptr,
int base)
Parameters:
nptr IN: The string containing the number to be parsed
endptr OUT: The pointer to the first character after the parsed number.
base IN: The base of the number (2..36) or 0.
Returns:
The parsed signed number.
*endptr is set to point to the first non-valid digit.
If converting the string to a number causes an overflow, LONG_MAX is returned. If converting causes an
underflow, LONG_MIN is returned. In both cases, *endptr is set equal to nptr.
If not a single digit could be parsed, 0 is returned and *endptr is set equal to nptr.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
14 Libstand API
2.2.1.3 strtoull
A function to parse an unsigned number from a string and return it as a number.
Synopsis:
unsigned long long strtoull(const char *nptr,
char **endptr,
int base)
Parameters:
nptr IN: The string containing the number to be parsed
endptr OUT: The pointer to the first character after the parsed number.
base IN: The base of the number (2..36) or 0.
Description:
At the beginning of the string, ASCII white-space characters, i.e., SPACE or TAB, will be skipped first. Then, any
number of + and - will be parsed to possibly return a negated value. Then, if the base is 0 or 16, a prefix of 0x or
0X will be skipped.
Then, any number of valid digits for the given base will be parsed. Digits are 0..9,a..z, in that order. Digits a..z
have values 10..35. The case of the letters is insignificant; upper case and lower case digits are treated the same.
Bases of 2 through 36 are valid, and 0 means ’autodetect’, which means 10 by default, unless the potential number
starts with 0x or 0X, which means base 16 will be assumed, or unless the potential number starts with 0, in which
case base 8 will be assumed. If the base is outside 0,2,3..36, no digit will be parsed.
Digits are valid if their value is strictly smaller than the assumed base.
If endptr is NULL, *endptr will not be written.
Returns:
The parsed unsigned number.
*endptr is set to point to the first non-valid digit.
If converting the string to a number causes an overflow or underflow, (unsigned long long)-1 is returned, and
*endptr is set equal to nptr.
If not a single digit could be parsed, 0 is returned and *endptr is set equal to nptr.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
ANSI C standard library functions 15
2.2.1.4 strtoll
A function to parse a signed number from a string and return it as a number. The behaviour is just like strtoul, but
for signed numbers.
Synopsis:
long long strtoll(const char *nptr,
char **endptr,
int base)
Parameters:
nptr IN: The string containing the number to be parsed
endptr OUT: The pointer to the first character after the parsed number.
base IN: The base of the number (2..36) or 0.
Returns:
The parsed signed number.
*endptr is set to point to the first non-valid digit.
If converting the string to a number causes an overflow, LLONG_MAX is returned. If converting causes an
underflow, LLONG_MIN is returned. In both cases, *endptr is set equal to nptr.
If not a single digit could be parsed, 0 is returned and *endptr is set equal to nptr.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
16 Libstand API
2.2.1.5 bsearch
Synopsis:
void* bsearch(const void *key,
const void *base,
size_t nmemb,
size_t size,
int(*compar)(const void *a,
const void *b))
Description:
Binary search.
Search a sorted array for an entry in O(log n) time.
Parameters:
[IN] key: Pointer to the key to search for
[IN] base: Base address of the array
[IN] nmemb: Number of elements in the array
[IN] size: Size of each element (in bytes)
[IN] compar: Comparison function: -1,0,+1 valued (like strcmp). key is always passed as the first object to
this comparison function.
Returns:
The pointer to the found array index if it was found, or NULL if the entry is not found. If multiple array elements are
equal to the key, it is unspecified which element is returned by this function.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
ANSI C string manipulation functions 17
2.3 ANSI C string manipulation functions
This section describes the subset of the ANSI C string manipulation functions included in libstand.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
18 Libstand API
2.3.1 Functions
2.3.1.1 strncat
Concatenate two strings by appending not more than n0 characters (including the terminating NUL character)
from the string pointed to by src to the string pointed to by s1. The first character of src overwrites the terminating
NUL character of s1. A terminating NUL character is always appended to the result. This means that the number
of characters appended to s1 may exceed n0 by one.
Synopsis:
char* strncat(char *dst,
const char *src,
size_t n0)
Parameters:
dst OUT: String to append to.
src IN: String which is appended from.
n0 IN: Number of characters to append.
Returns:
The pointer given as dst.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
ANSI C string manipulation functions 19
2.3.1.2 strncmp
Compare not more than the first n characters of the string pointed to by s1 and i.
Synopsis:
int strncmp(const char *a,
const char *i,
size_t n)
Parameters:
a IN: Pointer to a string which is compared.
i IN: Pointer to a string which is compared.
n IN: Number of characters to compare.
Returns:
If s1 sorts lexicographically after i, a value greater than than zero is returned. In the opposite case, a value smaller
than zero is returned. If the strings are equivalent, zero is returned.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
20 Libstand API
2.3.1.3 strcmp
Compare the string pointed to by s1 and s2.
Synopsis:
int strcmp(const char *s1,
const char *s2)
Parameters:
s1 IN: Pointer to a string which is compared.
s2 IN: Pointer to a string which is compared.
Returns:
If s1 sorts lexicographically after s2, a value greater than than zero is returned. In the opposite case, a value
smaller than zero is returned. If the strings are equivalent, zero is returned.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
ANSI C string manipulation functions 21
2.3.1.4 strncpy
Copy not more than n0 characters (including the terminating NUL character) from the string pointed to by src to
the string pointed to by dst0. If n0 is greater than the number of characters in src, NUL characters are appended
to src.
Synopsis:
char* strncpy(char *dst,
const char *src,
size_t n0)
Parameters:
dst IN: Pointer to the destination string.
src OUT: Pointer to the source string.
n0 IN: Number of characters to copy.
Returns:
The pointer given as dst.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
22 Libstand API
2.3.1.5 strlen
Determine the string length of the string pointed to by a str. The string length is the number of characters in the
string disreagrding the terminating NUL character.
Synopsis:
size_t strlen(const char *str)
Parameters:
str IN: The string to determine the length of.
Returns:
The number of characters the given string consists of without the terminating NUL character.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
ANSI C string manipulation functions 23
2.3.1.6 strnchr
Find the first occurrence of the character c_int (casted to unsigned char) in the first length characters of the string
pointed to by s.
Synopsis:
char* strnchr(const char *src_void,
size_t length,
int c_int)
Parameters:
src_void IN: Pointer to the string in which to find the specified character.
length IN: Number of bytes of the given string to scan for the specified character.
c_int IN: The character to find.
Returns:
A pointer to the first occurrence of the character c_int in s or NULL, if c_int is not contained in the first n characters
of s.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
24 Libstand API
2.3.1.7 strnrchr
Find the last occurrence of the character c (casted to unsigned char) in the first n characters of the string pointed
to by s.
Synopsis:
char* strnrchr(const char *s,
size_t n,
int c)
Parameters:
s IN: Pointer to the string in which to find the specified character.
n IN: Number of bytes of the given string to scan for the specified character.
c IN: The character to find.
Returns:
A pointer to the last occurrence of the character c in s or NULL, if c is not contained in the first n characters of s.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
ANSI C string manipulation functions 25
2.3.1.8 strnlen
Determine the number of characters in the string pointed to by str not taking the terminating NUL character into
account. Up to n characters are scanned.
Synopsis:
size_t strnlen(const char *str,
size_t n)
Parameters:
str IN: Pointer to the string to determine the length of.
n IN: Maximum length of the given string.
Returns:
The number of characters in the string pointed to by str not including the terminating NUL character or n if no
terminating NUL character is contained in the first n characters.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
26 Libstand API
2.3.1.9 strlcpy
Copy not more than n-1 characters (excluding the terminating NUL character) from the string pointed to by s to
the string pointed to by d. If count is > 0, dst0 is terminated with NUL.
Synopsis:
size_t strlcpy(char *d,
const char *s,
size_t n)
Parameters:
d IN: Pointer to the destination string.
s OUT: Pointer to the source string.
n IN: Number of characters to copy.
Returns:
The length of string dst0, excluding character 0, or count if the resulting string was too long.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
ANSI C string manipulation functions 27
2.3.1.10 strlcat
Concatenate two strings, making the result no longer than count-1 characters, excluding the terminating NUL. The
destination string is always NUL terminated.
Synopsis:
size_t strlcat(char *d,
const char *s,
size_t n)
Parameters:
d OUT: String to append to.
s IN: String which is appended from.
n IN: Number of characters to append.
Returns:
The length of the string s1, excluding character 0, or count if the resulting string was too long.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
28 Libstand API
2.3.1.11 memset
Set the first length bytes at the given memory address m to the value of c_int.
Synopsis:
void* memset(void *dst_void,
int c_int,
size_t length)
Parameters:
dst_void OUT: Start memory address.
c_int IN: The value to assign to each byte in the specified range.
length IN: The length, in bytes, of the range to modify.
Returns:
The pointer given as dst_void.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
ANSI C string manipulation functions 29
2.3.1.12 memchr
Find the first occurence of the byte c_int in the memory range specified by src_void and length.
Synopsis:
void* memchr(const void *src_void,
int c_int,
size_t length)
Parameters:
src_void IN: Start memory address.
c_int IN: The byte value to find.
length IN: The length, in bytes, of the range to search in.
Returns:
A pointer to the first occurrence of the byte c_int in the specified memory range or NULL, if the byte c_int does
not occur in the first length bytes.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
30 Libstand API
2.3.1.13 memcpy
Copy length bytes of the memory block starting at src0 to the memory block starting at dst_void.
Synopsis:
void* memcpy(void *dst_void,
const void *src_void,
size_t length)
Parameters:
dst_void OUT: Start address of the destination memory range.
src_void IN: Start address of the source memory range.
length IN: Number of bytes to copy from src_void to dst0.
Returns:
The pointer given as dst_void.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
ANSI C string manipulation functions 31
2.3.1.14 memmove
Copy len bytes of the memory block starting at src0 to the overlapping memory block starting at dst_void.
Synopsis:
void* memmove(void *dst_void,
const void *src_void,
size_t len)
Parameters:
dst_void OUT: Start address of the destination memory range.
src_void IN: Start address of the source memory range.
len IN: Number of bytes to copy from src_void to dst0.
Returns:
The pointer given as dst_void.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
32 Libstand API
2.3.1.15 memcmp
Compare n bytes of the contents of the memory range pointed to by s1 to the contents of the memory range
pointed to by b_void.
Synopsis:
int memcmp(const void *a_void,
const void *b_void,
size_t n)
Parameters:
a_void IN: Start address of the memory range to compare.
b_void IN: Start address of the memory range to compare.
n IN: Number of bytes to compare.
Returns:
A value greater than, equal to or smaller than zero, according to whether the memory range pointed to by a_void
is gearter than, equal to or smaller than the memory range pointed to by b_void.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
ANSI C standard types 33
2.4 ANSI C standard types
This sections describes the subset of the ANSI C standard types included in libstand.
2.4.1 Defines
LONG_MAX
P4X_LONG_MIN
LONG_MIN
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
34 Libstand API
2.5 Assert
2.5.1 Defines
assert (x)
Description:
Macro to check at runtime that a condition is true.
If the condition is not true, an assertion failure will be raised, ending execution of the current executable.
The assertion failure is raised by the runtime environment, e.g., when using libvm, i.e., in applications
and in external file providers and in volume providers, libvm contains the assertion failure function and
will, after printing an error message, halt the current partition. In kernel code, e.g. in kernel drivers, the
kernel will raise a kernel level health monitoring event when an assertion failure is triggered. In system
extensions, the PSSW will raise a health monitoring event when an assertion failure is triggered.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.

8864
docs-extracted/development/psp-development-guide.md Normal file
View file

File diff suppressed because it is too large Load diff

12386
docs-extracted/development/pssw-reference-manual.md Normal file
View file

File diff suppressed because it is too large Load diff

5309
docs-extracted/development/test-framework-reference-manual.md Normal file
View file

File diff suppressed because it is too large Load diff

3620
docs-extracted/development/volume-provider-reference-manual.md Normal file
View file

File diff suppressed because it is too large Load diff

9051
docs-extracted/hardware-virtualization/hardware-virtualization.md Normal file
View file

File diff suppressed because it is too large Load diff

62
docs-extracted/index.md Normal file
View file

@ -0,0 +1,62 @@
---
title: "PikeOS Documentation Extract Index"
generated: "2026-07-06T23:06:49.724638"
---
# PikeOS Documentation Extract Index
This index lists all 37 PikeOS PDF manuals that were successfully extracted to markdown.
Eight PDFs were empty (0 bytes) and could not be extracted; they are listed at the end.
| Document | Category | Source PDF |
|----------|----------|------------|
| [As User Manual](cdk/as-user-manual.md) | cdk | `docs/cdk/as-user-manual.pdf` |
| [Binutils User Manual](cdk/binutils-user-manual.md) | cdk | `docs/cdk/binutils-user-manual.pdf` |
| [Cpp Preprocessor User Manual](cdk/cpp-preprocessor-user-manual.md) | cdk | `docs/cdk/cpp-preprocessor-user-manual.pdf` |
| [Cpplib Internals](cdk/cpplib-internals.md) | cdk | `docs/cdk/cpplib-internals.pdf` |
| [Gcc Installation Manual](cdk/gcc-installation-manual.md) | cdk | `docs/cdk/gcc-installation-manual.pdf` |
| [Ld User Manual](cdk/ld-user-manual.md) | cdk | `docs/cdk/ld-user-manual.pdf` |
| [Anis Reference Manual](development/anis-reference-manual.md) | development | `docs/development/anis-reference-manual.pdf` |
| [Cfs Reference Manual](development/cfs-reference-manual.md) | development | `docs/development/cfs-reference-manual.pdf` |
| [Instrumentation Monitoring Reference Manual](development/instrumentation-monitoring-reference-manual.md) | development | `docs/development/instrumentation-monitoring-reference-manual.pdf` |
| [Kernel Reference Manual](development/kernel-reference-manual.md) | development | `docs/development/kernel-reference-manual.pdf` |
| [Libstand Reference Manual](development/libstand-reference-manual.md) | development | `docs/development/libstand-reference-manual.pdf` |
| [Psp Development Guide](development/psp-development-guide.md) | development | `docs/development/psp-development-guide.pdf` |
| [Pssw Reference Manual](development/pssw-reference-manual.md) | development | `docs/development/pssw-reference-manual.pdf` |
| [Test Framework Reference Manual](development/test-framework-reference-manual.md) | development | `docs/development/test-framework-reference-manual.pdf` |
| [Volume Provider Reference Manual](development/volume-provider-reference-manual.md) | development | `docs/development/volume-provider-reference-manual.pdf` |
| [Hardware Virtualization](hardware-virtualization/hardware-virtualization.md) | hardware-virtualization | `docs/hardware-virtualization/hardware-virtualization.pdf` |
| [Pikeos Installation Guide](pikeos-installation-guide.md) | general | `docs/pikeos-installation-guide.pdf` |
| [Pikeos C Programming Environment](pikeos-native/pikeos-c-programming-environment.md) | pikeos-native | `docs/pikeos-native/pikeos-c-programming-environment.pdf` |
| [Pikeos Cxx Programming Environment](pikeos-native/pikeos-cxx-programming-environment.md) | pikeos-native | `docs/pikeos-native/pikeos-cxx-programming-environment.pdf` |
| [Pikeos Native Api Extensions](pikeos-native/pikeos-native-api-extensions.md) | pikeos-native | `docs/pikeos-native/pikeos-native-api-extensions.pdf` |
| [Platform Manual Arm](platform/platform-manual-ARM.md) | platform | `docs/platform/platform-manual-ARM.pdf` |
| [Platform Manual Arm 64Bit](platform/platform-manual-ARM_64bit.md) | platform | `docs/platform/platform-manual-ARM_64bit.pdf` |
| [Platform Manual Ppc E500](platform/platform-manual-PPC_e500.md) | platform | `docs/platform/platform-manual-PPC_e500.pdf` |
| [Platform Manual Ppc E500Mc 4G](platform/platform-manual-PPC_e500mc-4g.md) | platform | `docs/platform/platform-manual-PPC_e500mc-4g.pdf` |
| [Platform Manual Ppc E500Mc](platform/platform-manual-PPC_e500mc.md) | platform | `docs/platform/platform-manual-PPC_e500mc.pdf` |
| [Platform Manual Ppc E5500](platform/platform-manual-PPC_e5500.md) | platform | `docs/platform/platform-manual-PPC_e5500.pdf` |
| [Platform Manual X86 Amd64](platform/platform-manual-x86_amd64.md) | platform | `docs/platform/platform-manual-x86_amd64.pdf` |
| [Posix Conformance](posix/posix-conformance.md) | posix | `docs/posix/posix-conformance.pdf` |
| [Posix Cxx](posix/posix-cxx.md) | posix | `docs/posix/posix-cxx.pdf` |
| [Posix Lwip](posix/posix-lwip.md) | posix | `docs/posix/posix-lwip.pdf` |
| [Releasenotes Anis 5.0.3](releasenotes/releasenotes-anis-5.0.3.md) | releasenotes | `docs/releasenotes/releasenotes-anis-5.0.3.pdf` |
| [Releasenotes Apex 5.0.3](releasenotes/releasenotes-apex-5.0.3.md) | releasenotes | `docs/releasenotes/releasenotes-apex-5.0.3.pdf` |
| [Releasenotes Bsp 5.0.3](releasenotes/releasenotes-bsp-5.0.3.md) | releasenotes | `docs/releasenotes/releasenotes-bsp-5.0.3.pdf` |
| [Releasenotes Cfs 5.0.3](releasenotes/releasenotes-cfs-5.0.3.md) | releasenotes | `docs/releasenotes/releasenotes-cfs-5.0.3.pdf` |
| [Releasenotes Hwvirt 5.0.3](releasenotes/releasenotes-hwvirt-5.0.3.md) | releasenotes | `docs/releasenotes/releasenotes-hwvirt-5.0.3.pdf` |
| [Releasenotes Pikeos 5.0.3](releasenotes/releasenotes-pikeos-5.0.3.md) | releasenotes | `docs/releasenotes/releasenotes-pikeos-5.0.3.pdf` |
| [Releasenotes Posix 5.0.3](releasenotes/releasenotes-posix-5.0.3.md) | releasenotes | `docs/releasenotes/releasenotes-posix-5.0.3.pdf` |
## Empty PDFs (not extracted)
| Source PDF |
|------------|
| `docs/codeo-user-manual.pdf` |
| `docs/pikeos-tutorials.pdf` |
| `docs/pikeos-user-manual.pdf` |
| `docs/apex/apex-personality.pdf` |
| `docs/cdk/gcc-internals.pdf` |
| `docs/cdk/gcc-user-manual.pdf` |
| `docs/development/driver-reference-manual.pdf` |
| `docs/posix/posix-personality.pdf` |

540
docs-extracted/pikeos-installation-guide.md Normal file
View file

@ -0,0 +1,540 @@
---
title: "Pikeos Installation Guide"
source: "docs/pikeos-installation-guide.pdf"
category: "general"
pages: 19
extracted: "2026-07-06T23:05:45.390794"
---
# Pikeos Installation Guide
> Extracted from `docs/pikeos-installation-guide.pdf` (19 pages).
> Figures, diagrams, and tables may not render accurately in plain text.
PikeOS 5.0
Installation Guide
Document Revision 5.0.3
PikeOS Installation Guide
Index
Installation Considerations ............................................................... 2
Host System Requirements for Linux ............................................ 2
Host System Requirements for Windows ...................................... 2
Installation ........................................................................................ 3
PikeOS Installation ........................................................................ 3
Linux/Android Personalities .......................................................... 7
Installing a Hotfix.......................................................................... 7
Installing Multiple Versions of PikeOS ......................................... 7
Verifying the Installation .............................................................. 7
Verifying the Hardware Setup ....................................................... 8
Uninstalling PikeOS........................................................................ 8
CODEO Installation ....................................................................... 8
PikeOS Licensing System ................................................................. 11
License Manager Troubleshooting .............................................. 16
Further Information .................................................................... 17
 Copyright 2005-2019 SYSGO GmbH Page 1
PikeOS Installation Guide
Installation Considerations
Host System Requirements for Linux
The PikeOS distribution comes with a complete set of tools for the development
and configuration of PikeOS-based systems. These tools are currently supported
in a cross-development environment running on a standard PC Linux host.
Although the tool chain is generally independent of the Linux distribution being
used on the PC, a number of software packages are required that may not be
installed by default in the Linux distribution. These are listed in the following
table, along with package version numbers which have been verified to properly
work with PikeOS. Thus, before installing the PikeOS distribution, you should
check whether these packages are present on your host system, and install or
update them as required.
Package Description
glibc 2.11.3 or newer C library. Required.
JRE 8 or compatible Java Runtime Environment. Required.
GTK 3.x The GIMP Tool Kit, needed by the Eclipse
framework. Required.
libxtst6 Needed by the Eclipse framework. Required.
libasound2 ALSA sound library, required for QEMU.
libX11 X Windowing system library, required for QEMU.
Its components xcb, Xau and Xdmcp are also
required.
GNU Bash 4.1 or newer Shell command line interpreter. Required.
Perl 5 Programming language. Required.
kermit Used as terminal emulator for serial connection to
target. Optional.
minicom An alternative to kermit for serial connection to
target. Optional.
Contrary to previous versions, PikeOS and CODEO require a 64-bit Java
Runtime Environment. 32-bit is no longer supported!
For more details please see the support FAQ, entry “CODEO Installation
Considerations” at
 http://www.sysgo.com/support/ 
Host System Requirements for Windows
PikeOS can be used on the following variants of the Windows operating system:
Windows 7, Windows 8 and Windows 10.
Just like PikeOS for Linux, a 64-bit Java Runtime Environment version 8 or
compatible has to be installed!
 Copyright 2005-2019 SYSGO GmbH Page 2
PikeOS Installation Guide
Installation
The PikeOS installation medium contains the PikeOS core components and the
CODEO IDE. For easy installation an interactive installation program can be
found in the root directory. Please note that you have to install PikeOS before
installing CODEO.
PikeOS Installation
Windows:
It is recommended to install PikeOS from a full Administrator account. Navigate
to the top level directory on the PikeOS installation medium, then double-click on
the following application: PikeOS-5.0-Windows-Setup.exe
To display the command line options of the installer open a command prompt
window and type:
PikeOS-5.0-Windows-Setup.exe --help
Linux:
You need root privileges during the installation. Please mount the PikeOS
installation medium, then change into the mount directory and run the
installation program. Assuming the medium has been mounted on
/media/dvdrom, the following commands can be entered from a terminal
window in order to start the installation:
cd /media/dvdrom
sudo ./PikeOS-5.0-Linux-Install.sh
(to display the command line options of the installer add: –-help)
Note: Some Linux distributions mount with the noexec option which disables the
execution of files on the installation medium. In this case you have to remount using
mount –o remount,exec /media/dvdrom
The following screen (fig. 1) will appear:
Please click on the “Next>” button in order to proceed. At this point, you will be
asked to accept the terms of the PikeOS license agreement in order
 Copyright 2005-2019 SYSGO GmbH Page 3
PikeOS Installation Guide
Figure 1: PikeOS Installation Start
to proceed with the installation. If you accept, you will be asked to enter the
installation key for the media (fig. 2). In the next step you can select the PikeOS
components you wish to install (fig. 3).
Then the PikeOS installation base directory will be shown (fig. 4).
Windows: Please note that the installation directory must not contain spaces or
special characters.
Linux: Please note that the installation directory is fixed and cannot be modified.
After confirming the installation directory with “Next>”, the installation details
will be shown (see fig. 5). Upon accepting the installation settings, the
installation process will begin and progress will be displayed (see fig. 6).
Windows: If not already present on your computer, the Cygwin environment will
also be installed at that time.
 Copyright 2005-2019 SYSGO GmbH Page 4
PikeOS Installation Guide
Figure 2: Entering the Installation Key
Figure 3: PikeOS Component Selection
 Copyright 2005-2019 SYSGO GmbH Page 5
PikeOS Installation Guide
Figure 4: Select Installation Location
Figure 5: PikeOS Installation Details
 Copyright 2005-2019 SYSGO GmbH Page 6
PikeOS Installation Guide
Figure 6: PikeOS Installation in Progress
Linux/Android Personalities
The Linux and Android personalities are not part of this PikeOS installation and
are shipped on a separate medium.
Installing a Hotfix
When installing a hotfix, please note that the main product needs to be installed
first, and after that the hotfix must be installed!
Installing Multiple Versions of PikeOS
PikeOS installations for different targets may coexist on your development
system, so you don’t need to take any special precautions when installing an
additional target platform. The same applies for installing different versions of
PikeOS for one target platform. Just repeat the standard installation procedure
with the other installation media. Next time when configuring a PikeOS project,
you will be able to select the newly installed platform or version.
Please note that the above only applies to unique different PikeOS versions. You
cannot install e.g. version X.Y twice or more on one system! This also applies to
Service Releases, please uninstall the previous (Service) Release before
installing the new one!
Verifying the Installation
The managing of PikeOS components is based on the well-known package man-
 Copyright 2005-2019 SYSGO GmbH Page 7
PikeOS Installation Guide
agement tool RPM. PikeOS brings its own RPM binary called pikeos-rpm. This
tool operates entirely on its own package database, so you neither have to install
RPM on non-RPM based distributions, nor do you have to be afraid that your in-
stallation could be compromised in any way by using pikeos-rpm. This section
lists a couple of useful RPM commands and queries.
By entering the following command after the installation has been completed,
you will receive a list of all packages installed:
/opt/pikeos-5.0/bin/pikeos-rpm –qa
Package information can be displayed, too. To display all information about the
installed package scripts, for instance, you enter:
/opt/pikeos-5.0/bin/pikeos-rpm -qi pikeos-scripts
To determine the package providing a certain file, enter:
/opt/pikeos-5.0/bin/pikeos-rpm -qf /opt/pikeos-5.0/bin/muxa
Verifying the Hardware Setup
In order to successfully develop with PikeOS, your hardware must be set up
properly. For example, many embedded targets are configured and booted by
some sort of boot loader which is accessed via a serial connection. Boot images
are usually downloaded from the development host to the target across an
Ethernet line. TFTP, BOOTP, and DHCP are service protocols which are typically
used for this purpose.
To verify your hardware setup, read the corresponding sections in the PikeOS
Platform Manual for your target hardware. There are precompiled binaries
available to test the general infrastructure of your setup and the working order of
your target.
To learn more about setting up required network servers, see the PikeOS User
Manual. You should also read the documentation that came with your
distribution.
Uninstalling PikeOS
Windows:
Uninstall PikeOS through the Windows Control Panel.
Linux:
An uninstall of PikeOS is done by simply deleting the PikeOS directory
you want to be removed from /opt, e.g.:
rm -rf /opt/pikeos-5.0
In this manner all PikeOS components are deleted from your system. Only the
data specific to the individual users’ projects will be retained. Alternatively, you
may run the script uninstall-pikeos.
CODEO Installation
Windows:
Navigate to the top-level directory of the CODEO installation medium, then
double-click on the following application: CODEO-7.0-Windows-Setup (the
 Copyright 2005-2019 SYSGO GmbH Page 8
PikeOS Installation Guide
actual filename is CODEO-7.0-Windows-Setup.exe).
To display the command line options of the installer open a command prompt
window and type:
CODEO-7.0-Windows-Setup.exe --help
Linux:
You need root privileges during the installation. Please mount the CODEO
installation medium and change into the mount directory. Assuming the CODEO
medium has been mounted on /media/dvdrom, the following commands can be
entered from a terminal window in order to start the CODEO installation:
cd /media/dvdrom
sudo ./CODEO-7.0-Linux-Install.sh
(to display the command line options of the installer add: –-help)
The following screen will appear (fig. 7). Please click “Next>” to continue. At this
point, you will be asked to accept the terms of the CODEO license agreement in
order to proceed with the installation. If you do not accept, the installation
process will be aborted.
Figure 7: CODEO Installation Start
 Copyright 2005-2019 SYSGO GmbH Page 9
PikeOS Installation Guide
Windows: You might be asked to update your Cygwin installation. If you have
installed the Cygwin version delivered with PikeOS this can be safely skipped.
The path to the Java VM can be either selected manually or detected by the
installer.
The next screen (fig. 8) shows where CODEO will be installed (this path is fixed
and cannot be changed). When you click “Next>”, the installation process begins
and progress is displayed.
CODEO installation is now complete and ready for usage.
Figure 8: CODEO Installation Details
 Copyright 2005-2019 SYSGO GmbH Page 10
PikeOS Installation Guide
PikeOS Licensing System
To match different business needs, SYSGO offers several licensing schemes for
PikeOS: “single-user”, “flexible” and “site”. Technically, all schemes have in
common that one or more license servers run at your site that authorize the
usage of the PikeOS development environment. Each license server operates on
one or more license files defining the licensed features. These files are generated
for you by SYSGO based on information that you have provided to SYSGO (the
so-called “Host ID”). For “flexible” and “site” licenses, one license server can serve
multiple PikeOS installations. If a “single-user” licensing model has been chosen,
then a license manager must be running on each physical machine where PikeOS
is used.
PikeOS is shipped with an installation license file. This license allows unrestricted
usage of PikeOS for a maximum of 30 days. Within this time frame the product
needs to be activated which is described below.
License management services under PikeOS are performed by the LM-X license
management system. The installer for the license manager is contained on the
installation medium for PikeOS and must be run separately to install LM-X. The
license manager can be installed on any machine in the network.
1. Installing the License Manager
1.1 Windows
On your PikeOS installation medium look for the folder “licensing”. Run
the installer lmx-enduser-tools_win64_x64.msi. When asked for
the “vendor library” (see image below) use the “Browse…” button to
navigate to the “licensing” folder on the installation medium. Here, you
find the DLL liblmxvendor.dll. Select this file and continue.
If you select “Install LM-X license server as a service”, the license server
is started automatically each time the Windows system reboots.
Otherwise you have to start the server manually.
 Copyright 2005-2019 SYSGO GmbH Page 11
PikeOS Installation Guide
Figure 9: Gathering Installation Information on Windows
1.2 Linux
On your PikeOS installation medium look for the folder “licensing”. Run
the installer lmx-enduser-tools_linux_x64.sh. When asked for the
“vendor library” enter the path to the “licensing” folder on the
installation medium, e.g. /mnt/licensing and press Enter. Select the
file liblmxvendor.so at the next prompt and continue.
The installer will ask you whether you want to install a startup script. If
you answer “Y”, a script is generated to start the license server
automatically each time the Linux system reboots. Otherwise you have
to start the server manually.
2. Collecting the “Host ID” for Licensing
2.1 License Manager Running on Windows
To obtain your license file, you must first get the necessary information
(hereafter called ”Host ID”) from the host machine which will act as
your license server. To do this, start the LM-X Configuration Tool. From
the “START” menu and select “X-Formation > LM-X Configuration Tool”.
Remark: Executing the tool will trigger a registry change which requires
administrator privileges.
In the LM-X Configuration Tool, select the “Hostid” tab, then save the
information to a file using the “Save To File” button (fig. 10).
 Copyright 2005-2019 SYSGO GmbH Page 12
PikeOS Installation Guide
Figure 10: Gathering “Host ID” Information
2.2 License Manager Running on Linux
Issue the following command from a terminal window:
/<path to the lmx installation>/lmxendutil -hostid >
hostid.txt
2.3 Dealing with Virtual Machines
If you intend to use PikeOS with a “single-user” license in a virtual
machine you have to generate two ”Host ID” files (selecting steps 2.1
and/or 2.2 as applicable): One is generated from the license data
collection tool within the VM and the other from the license data
collection tool outside of the VM. Please indicate which of them was
generated outside of the VM when sending them to SYSGO. For
“flexible” or “site” licenses this is not required.
3. Communicating the ”Host ID” information to SYSGO
Please e-mail the hostid.txt file(s) to licensing@sysgo.com together with either
your order reference or the installation license file. On reception, SYSGO will
create your license file based on your ordering information and ”Host ID”
information and send it to you.
4. Installing your License File
License files are in plain text format with Unix style line breaks. They are simply
copied into the same folder where the LM-X license server is installed. Then you
restart the license server and you are done.
 Copyright 2005-2019 SYSGO GmbH Page 13
PikeOS Installation Guide
5. Starting the License Server
5.1 Windows
If you opted to install the LM-X license server as a service during the LM-
X enduser tools installation, you are done. The service will be started
automatically each time the machine reboots.
Otherwise you must manually start the server. Open the “START” menu
and select “X-Formation > Start LM-X license server”. The server can be
stopped by selecting “X-Formation > Stop LM-X license server” from the
“START” menu.
To make sure the server is running and your licenses are available, select
the “Query License Server” tab of the configuration tool. Enter the
name of the server and the port number (usually 6200), then press the
“Perform” button. The available licenses will be displayed as follows
(fig. 11):
Figure 11: Querying the License Server
5.2 Linux
If you opted to install a startup script for the LM-X license server during
the LM-X enduser tools installation, you are done. The service will be
started automatically each time the machine reboots. The server can be
started and stopped by issuing:
service lmxserv494 start/stop
on the command line.
 Copyright 2005-2019 SYSGO GmbH Page 14
PikeOS Installation Guide
Otherwise you must manually start the server like this:
/<path to the lmx installation>/lmx-serv
Depending on the permissions set on the installation folder you may
need root privileges. The server will run in the background and log its
activity in the file /<path to the lmx installation>/lmx-
serv.log.
6. Using PikeOS
PikeOS tools must be told which license server to use.
For Windows start the license manager configuration tool and select the “Client
Application License Path”, then press “Add Network Host” (fig. 12). Host is
localhost or 127.0.0.1 (for a local license server, otherwise enter the remote
server‘s name) and Port is 6200 (unless you are using a remote license server
configured with a different port number). Click on “Save Changes” after you have
completed the configuration.
Figure 12: Configuring the Path to the License Server
For Linux enter the following command prior to using PikeOS:
export SYSGO_LICENSE_PATH=6200@host
“host” is the host name or IP address of the computer on which the license server
is running. “6200” indicates the port number on which the license server should
 Copyright 2005-2019 SYSGO GmbH Page 15
PikeOS Installation Guide
be contacted. It may be handy to place the definition of SYSGO_LICENSE_PATH
in your shell startup file, for instance in the “.profile”.
Congratulations, you are now ready to use PikeOS!
The complete end-user manual for LM-X can be found at https://docs.x-
formation.com/display/LMX/LM-X+End+Users+Guide
License Manager Troubleshooting
If you encounter any problems installing or using your PikeOS license key please
check the log file of the license manager.
Please revise your network configuration if the log file does not list any
connection attempts at all. A firewall might have blocked the license requests.
If the problem cannot be resolved please contact SYSGO using the support
website or licensing@sysgo.com and include the log file of the license manager.
 Copyright 2005-2019 SYSGO GmbH Page 16
PikeOS Installation Guide
Further Information
Please refer to the product documentation for additional information. The
documents are located in the “documentation” folder of the installation medium
and on your hard disk after installation.
Answers to frequently asked questions (FAQ) and resolutions to known issues are
updated on a regular basis. These are available online at
http://www.sysgo.com/support/
Product support is available online at http://www.sysgo.com/support/
Product updates will be provided for download on
https://www.sysgo.com/downloadserver/
To access these websites please login using your account as stated on the
delivery document.
 Copyright 2005-2019 SYSGO GmbH Page 17
PikeOS Installation Guide
SYSGO GmbH Phone +49 6136 99480
Am Pfaffenstein 14 Fax +49 6136 994810
D-55270 Klein-Winternheim www.sysgo.com
 Copyright 2005-2019 SYSGO GmbH Page 18

1029
docs-extracted/pikeos-native/pikeos-c-programming-environment.md Normal file
View file

File diff suppressed because it is too large Load diff

210
docs-extracted/pikeos-native/pikeos-cxx-programming-environment.md Normal file
View file

@ -0,0 +1,210 @@
---
title: "Pikeos Cxx Programming Environment"
source: "docs/pikeos-native/pikeos-cxx-programming-environment.pdf"
category: "pikeos-native"
pages: 9
extracted: "2026-07-06T23:06:05.551097"
---
# Pikeos Cxx Programming Environment
> Extracted from `docs/pikeos-native/pikeos-cxx-programming-environment.pdf` (9 pages).
> Figures, diagrams, and tables may not render accurately in plain text.
CPPENV
C++ Language Programming
Environment
Am Pfaffenstein 14, D-55270 Klein-Winternheim
Notice: The contents of this document are proprietary to
SYSGO GmbH and shall not be disclosed, disseminated,
copied, or used except for purposes expressly
authorized in writing by SYSGO GmbH.
C++ Language Programming Environment
PikeOS D5.0, Document Version D5.0-30
c 2005 – 2019 SYSGO GmbH
SYSGO GmbH Email: office@sysgo.com
Am Pfaffenstein 14
55270 Klein-Winternheim, Germany http://www.sysgo.com
All rights reserved.
PikeOS is a trademark of SYSGO GmbH. The designations used to identify other software or hardware products
in this publication may be trademarks of their manufacturers or sellers.
Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Known Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Architecture Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3 Project Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4 Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5 Library Summary: C++ Support Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1 C Language Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.2 C++ Language Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6 Library Summary: C++ Standard Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
4 Introduction
1 Introduction
The PikeOS C++ language programming environment (CPPENV) further extends the PikeOS native personality
providing a C++ programming environment to the application programmer.
Section 3 describes application project configuration parameters, section 4 contains a summary of the files
comprising the PikeOS C++ language programming environment.
The PikeOS C++ language programming environment is currently only available to PikeOS applications using the
PikeOS native personality. In future releases, the C++ language programming environment will be made available
to other PikeOS personalities and components.
1.1 Known Limitations
• When including PikeOS include files (for example <p4.h>), the application programmer may have to
provide appropriate linkage specifications for use in C++ context, for example
#ifdef __cplusplus
extern "C" {
#endif
#include <p4.h>
#include <vm.h>
#ifdef __cplusplus
}
#endif
or using definitions from P4EXT or CENV (provided by most P4EXT or CENV headers or by including
<p4ext/p4ext_cdefs.h> or <sys/cdefs.h>)
__BEGIN_DECLS
#include <p4.h>
__END_DECLS
• The name demangling function __cxa_demangle() is not supported.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
5
2 Architecture Dependencies
C++ exception handling and stack unwinding may issue floating-point instructions on certain architectures.
Threads making use of C++ exceptions should therefore be created with appropriate thread context creation
flags (e.g. P4_THREAD_ARG_FPU set).
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
6 Project Configuration
3 Project Configuration
The use of the C++ language programming environment is currently limited to PikeOS native applications.
The C++ language programming environment consists of two parts. One part consists of headers and object code
libraries providing support functions for the C++ compiler (libsupcxx). The second part consists of a subset of
the C++ standard library.
In the configuration of PikeOS native applications support for the C++ language programming environment is
enabled by configuration parameter PIKEOS_CXX. Enabling this parameter adds the definition of feature test
macro PIKEOSCPPENV to the C++ compiler command line and adds the C++ compiler support library to the linker
command line.
If required by the application program, the PikeOS C language programming environment (PIKEOS_CENV,
PIKEOS_CENV_LIBM) can be used in combination with the C++ language support.
The C++ standard library subset is enabled by configuration parameter PIKEOS_CXX_STL, this parameter de-
pends on PIKEOS_CXX and PIKEOS_CENV being enabled. Enabling parameter PIKEOS_CXX_STL extends the
include file search path to locate the C++ standard library headers and adds the C++ standard library to the linker
command line.
Filename extensions .cc, .cpp, and .C are supported for C++ source files.
The C++ language standard for source code and library versions is configured by parameter PIKEOS_CXX_STD.
The currently supported value is c++98.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
7
4 Files
C++ language support header files for the C++ language programming environment are installed in
$PIKEOS_TARGET_FILES/include/c++98.
The C++ language compiler support library is installed in $PIKEOS_TARGET_FILES/lib/libsupcxx-c++98.a.
Header files and object code libraries for the C++ standard library
are installed in$PIKEOS_TARGET_FILES/cppenv/include/c++98 and
$PIKEOS_TARGET_FILES/cppenv/lib/libstdcxx-c++98.a, respectively.
Makefile definitions and rules for use of the PikeOS C++ language programming environment in PikeOS native
applications are found in $PIKEOS_TARGET_FILES/scripts/pikeos/cxx.mk.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
8 Library Summary: C++ Support Library
5 Library Summary: C++ Support Library
5.1 C Language Support
<cassert> Diagnostics macro.
<cctype> Character type handling.
<cerrno> Error number.
<cfloat> Characteristics of floating types.
<ciso646> Empty header. The macros that appear in iso646.h in C are keywords in C++.
<climits> Limits of integer types.
<clocale> C localization utilities.
<cmath> Mathematics.
<csetjmp> Non-local goto.
<cstdarg> Handling of variable length argument lists.
<cstddef> Typedefs for types such as size_t, NULL and others.
<cstdio> C input/output functions.
<cstdlib> General purpose utilities.
<cstring> C character string handling.
Note that limitations of the PikeOS C language programming environment (CENV) are reflected by these headers,
for example <cstdio> is limited to formatted input and output on C string buffers.
5.2 C++ Language Support
<exception> Exception handling utilities.
<new> Low-level memory management utilities.
<typeinfo> Runtime type information utilities.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
9
6 Library Summary: C++ Standard Library
<algorithm> Algorithms that operate on containers.
<bitset> std::bitset class template.
<deque> std::deque container.
<functional> Function objects, designed for use with the standard algorithms.
<iterator> Container iterators.
<limits> Standardized way to query properties of fundamental types.
<list> std::list container.
<map> std::map and std::multimap associative containers.
<memory> Higher level memory management utilities.
<numeric> Numeric operations on values in containers.
<queue> std::queue and std::priority_queue container adaptors.
<set> std::set and std::multiset associative containers.
<stack> std::stack container adaptor.
<stdexcept> Standard exception objects.
<string> std::basic_string class template.
<utility> Various utility components.
<valarray> Class for representing and manipulating arrays of values.
<vector> std::vector container.
Note that limitations of the PikeOS C language programming environment (CENV) are reflected by these headers,
for example <string> does not support wide character strings.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.

1946
docs-extracted/pikeos-native/pikeos-native-api-extensions.md Normal file
View file

File diff suppressed because it is too large Load diff

7144
docs-extracted/platform/platform-manual-ARM.md Normal file
View file

File diff suppressed because it is too large Load diff

5887
docs-extracted/platform/platform-manual-ARM_64bit.md Normal file
View file

File diff suppressed because it is too large Load diff

2903
docs-extracted/platform/platform-manual-PPC_e500.md Normal file
View file

File diff suppressed because it is too large Load diff

4115
docs-extracted/platform/platform-manual-PPC_e500mc-4g.md Normal file
View file

File diff suppressed because it is too large Load diff

4093
docs-extracted/platform/platform-manual-PPC_e500mc.md Normal file
View file

File diff suppressed because it is too large Load diff

3791
docs-extracted/platform/platform-manual-PPC_e5500.md Normal file
View file

File diff suppressed because it is too large Load diff

4550
docs-extracted/platform/platform-manual-x86_amd64.md Normal file
View file

File diff suppressed because it is too large Load diff

2094
docs-extracted/posix/posix-conformance.md Normal file
View file

File diff suppressed because it is too large Load diff

3153
docs-extracted/posix/posix-cxx.md Normal file
View file

File diff suppressed because it is too large Load diff

1779
docs-extracted/posix/posix-lwip.md Normal file
View file

File diff suppressed because it is too large Load diff

227
docs-extracted/releasenotes/releasenotes-anis-5.0.3.md Normal file
View file

@ -0,0 +1,227 @@
---
title: "Releasenotes Anis 5.0.3"
source: "docs/releasenotes/releasenotes-anis-5.0.3.pdf"
category: "releasenotes"
pages: 5
extracted: "2026-07-06T23:05:50.887426"
---
# Releasenotes Anis 5.0.3
> Extracted from `docs/releasenotes/releasenotes-anis-5.0.3.pdf` (5 pages).
> Figures, diagrams, and tables may not render accurately in plain text.
Release Notes
1 Product Release Information
Product Name: ANIS for PikeOS 5.0
Release and Build Number: 5.0.3/D5879
Release Date: 20082019
2 Introduction
This document contains the release notes for ANIS for PikeOS 5.0 (Avionics Network IP Stack), build D5879. The following
sections describe the release in detail and provide information that supplements the main documentation.
Each release may also include some undisclosed security patches. For details of those patches, a certified product license
and the related support contract must be in place.
3 Installation and Upgrade News
3.1 Installation
Please see the manual PikeOS Installation Guide for more details.
3.2 Release Features
This release consists of the following components:
• ANIS for PikeOS File Provider for PikeOS
• ANIS for PikeOS Native PikeOS API
• ANIS for PikeOS POSIX API
4 Recent User Visible Changes
4.1 Enhancements introduced by this Release
None.
4.2 Problems fixed with this Release
None.
4.3 Known Problems
Issue P00118-130, POSIX socket services in presence of thread cancellation
POSIX socket functions are not cancellation safe. Applications using thread cancellation should disable cancellation
prior to entering socket services.
c Copyright 2019 1
All rights reserved.
SYSGO GmbH
Release Notes
A Previous Release 5.0.2 S5804
A.1 Enhancements introduced by this Release
Issue P00118-457, Link-Status of an Ethernet Interface
It is now possible to read the link status of an Ethernet interface assigned to ANIS through the instrumentation interface.
Issue P00118-478, Configuration on File-Provider Startup
A feature was added to allow configuration of ANIS at startup. Please refer to the ANIS manual section 2.4.
Issue P00118-501, ANIS Run-Time Configuration Demo added
A demo program for PikeOS native personality was added to demonstrate how to use the run-time configuration of
ANIS.
Issue P00118-555, Support startup Configuration File on a Volume Provider
It is now possible to store and use a ANIS startup configuration file on a volume provider.
A.2 Problems fixed with this Release
Issue P00118-311, The ANIS API for PikeOS native application is not multicore-safe
PikeOS native applications using the ANIS API must make sure that API functions are only called by threads running
on the same core.
Issue P00118-462, HM Error upon receiving large Packets
An issue that led to a HM error upon receiving a packet larger than the configured MTU was fixed.
Issue P00118-465, Possible data delivery to wrong socket when using SO_REUSEADDR
If a datagram can be delivered to two or more sockets (possible with SO_REUSEADDR), ANIS delivers it now to the
socket that was bound first.
Issue P00118-471, ANISFP configuration allows selection of the program image
The ANISFP configuration now allows to select the binary origin of the file provider program image.
Issue P00118-482, Incompatible Definition of size_t
The PikeOS Native API header socket.h provided a definition of size_t which was not in-line with the PikeOS compiler
configuration. This issue was fixed.
Issue P00118-510, ANIS File Provider Maximum Controlled Priority Restriction
The ANIS file provider needs at least four scheduling priority levels for its internal threads. A project configurator
parameter restriction and a run-time check were added to ensure that the maximum controlled priority of the ANIS file
provider process is greater than or equal to 4.
Issue P00118-515, Wrong Error-Code when running out of free Sockets at Init-Phase
An issue was fixed that leads to a return value of ANIS_E_SYS when running out of available sockets and initialization
phase.
Issue P00118-549, Debugging of PikeOS Native Applications using ANIS not possible
An issue was fixed that made it impossible to debug PikeOS Native applications using ANIS.
A.3 Known Problems
Issue P00118-130, POSIX socket services in presence of thread cancellation
POSIX socket functions are not cancellation safe. Applications using thread cancellation should disable cancellation
prior to entering socket services.
c Copyright 2019 2
All rights reserved.
SYSGO GmbH
Release Notes
B Previous Release 5.0.1.1 S5500
B.1 Enhancements introduced by this Release
None.
B.2 Problems fixed with this Release
Issue P00118-462, HM Error upon receiving large Packets
An issue that led to a HM error upon receiving a packet larger than the configured MTU was fixed.
Issue P00118-482, Incompatible Definition of size_t
The PikeOS Native API header socket.h provided a definition of size_t which was not in-line with the PikeOS compiler
configuration. This issue was fixed.
B.3 Known Problems
Issue P00118-130, POSIX socket services in presence of thread cancellation
POSIX socket functions are not cancellation safe. Applications using thread cancellation should disable cancellation
prior to entering socket services.
Issue P00118-311, The ANIS API for PikeOS native application is not multicore-safe
PikeOS native applications using the ANIS API must make sure that API functions are only called by threads running
on the same core.
c Copyright 2019 3
All rights reserved.
SYSGO GmbH
Release Notes
C Previous Release 5.0.1 S5440
C.1 Enhancements introduced by this Release
None.
C.2 Problems fixed with this Release
Issue P00118-459, Handling of multicast Ethernet address collisions
An issue was fixed that could lead to disabled reception of multicast Ethernet frames. Affected IPv4 addresses
share the same lower 23 bits (for example: 239.0.0.0 and 239.128.0.0) and the error occurs after dropping multicast
membership of such an address.
C.3 Known Problems
Issue P00118-130, POSIX socket services in presence of thread cancellation
POSIX socket functions are not cancellation safe. Applications using thread cancellation should disable cancellation
prior to entering socket services.
Issue P00118-311, The ANIS API for PikeOS native application is not multicore-safe
PikeOS native applications using the ANIS API must make sure that API functions are only called by threads running
on the same core.
c Copyright 2019 4
All rights reserved.
SYSGO GmbH
Release Notes
D Previous Release 5.0 S5319
D.1 Enhancements introduced by this Release
None.
D.2 Problems fixed with this Release
Issue P00118-451, Structure anis_instr_stat aligned between POSIX- and PikeOS native API
The structure anis_instr_stat in instr.h was aligned between POSIX- and PikeOS native API.
D.3 Known Problems
Issue P00118-130, POSIX socket services in presence of thread cancellation
POSIX socket functions are not cancellation safe. Applications using thread cancellation should disable cancellation
prior to entering socket services.
Issue P00118-311, The ANIS API for PikeOS native application is not multicore-safe
PikeOS native applications using the ANIS API must make sure that API functions are only called by threads running
on the same core.
c Copyright 2019 5
All rights reserved.
SYSGO GmbH

1600
docs-extracted/releasenotes/releasenotes-apex-5.0.3.md Normal file
View file

File diff suppressed because it is too large Load diff

1389
docs-extracted/releasenotes/releasenotes-bsp-5.0.3.md Normal file
View file

File diff suppressed because it is too large Load diff

186
docs-extracted/releasenotes/releasenotes-cfs-5.0.3.md Normal file
View file

@ -0,0 +1,186 @@
---
title: "Releasenotes Cfs 5.0.3"
source: "docs/releasenotes/releasenotes-cfs-5.0.3.pdf"
category: "releasenotes"
pages: 5
extracted: "2026-07-06T23:05:51.005498"
---
# Releasenotes Cfs 5.0.3
> Extracted from `docs/releasenotes/releasenotes-cfs-5.0.3.pdf` (5 pages).
> Figures, diagrams, and tables may not render accurately in plain text.
Release Notes
1 Product Release Information
Product Name: CFS for PikeOS 5.0
Release and Build Number: 5.0.3/D000
Release Date: 00.00.0000
2 Introduction
This document contains the release notes for CFS for PikeOS 5.0, build D000. The following sections describe the release
in detail and provide information that supplements the main documentation.
Each release may also include some undisclosed security patches. For details of those patches, a certified product license
and the related support contract must be in place.
3 Installation and Upgrade News
3.1 Installation
Please see the manual PikeOS Installation Guide for more details.
3.2 Release Features
This release consists of the following components:
• CFS library for the PikeOS personality
• CFS library for the POSIX personality
4 Recent User Visible Changes
4.1 Enhancements introduced by this Release
None.
4.2 Problems fixed with this Release
None.
4.3 Known Problems
Issue P00119-284, Duplicate file names are not handled by file system check
When an error occurs in the file system so that two (or more) files within one directory have the same name, the file
system check will not detect this. The second (and further) file(s) won’t be accessible - until the first one is deleted.
Note: This cannot happen during a regular operation. Duplicated file names will be rejected during file/directory
creation.
c Copyright 2019 1
All rights reserved.
SYSGO GmbH
Release Notes
A Previous Release 5.0.2 S5804
A.1 Enhancements introduced by this Release
Issue P00119-476, Avoid unnecessary flushing of Inodes
An issue was resolved to avoid writing out inodes when no content change took place.
A.2 Problems fixed with this Release
None.
A.3 Known Problems
Issue P00119-284, Duplicate file names are not handled by file system check
When an error occurs in the file system so that two (or more) files within one directory have the same name, the file
system check will not detect this. The second (and further) file(s) won’t be accessible - until the first one is deleted.
Note: This cannot happen during a regular operation. Duplicated file names will be rejected during file/directory
creation.
c Copyright 2019 2
All rights reserved.
SYSGO GmbH
Release Notes
B Previous Release 5.0.1.1 S5500
B.1 Enhancements introduced by this Release
None.
B.2 Problems fixed with this Release
None.
B.3 Known Problems
Issue P00119-284, Duplicate file names are not handled by file system check
When an error occurs in the file system so that two (or more) files within one directory have the same name, the file
system check will not detect this. The second (and further) file(s) won’t be accessible - until the first one is deleted.
Note: This cannot happen during a regular operation. Duplicated file names will be rejected during file/directory
creation.
c Copyright 2019 3
All rights reserved.
SYSGO GmbH
Release Notes
C Previous Release 5.0.1 S5440
C.1 Enhancements introduced by this Release
Issue P00119-476, Avoid unnecessary flushing of Inodes
An issue was resolved to avoid writing out inodes when no content change took place.
C.2 Problems fixed with this Release
None.
C.3 Known Problems
Issue P00119-284, Duplicate file names are not handled by file system check
When an error occurs in the file system so that two (or more) files within one directory have the same name, the file
system check will not detect this. The second (and further) file(s) won’t be accessible - until the first one is deleted.
Note: This cannot happen during a regular operation. Duplicated file names will be rejected during file/directory
creation.
c Copyright 2019 4
All rights reserved.
SYSGO GmbH
Release Notes
D Previous Release 5.0 S5319
D.1 Enhancements introduced by this Release
Issue P00119-449, Clear internal memory pools prior to usage
The CFS implementation now takes care about clearing memory pools before (re-)using them.
Issue P00119-462, CFS image size part of the filesystem information output
The cfs-tool info command displays now also the size of the CFS filesystem given during creation of the filesystem
image.
Issue P00119-463, cfs-tool’s list output show file modification time
The verbose mode of cfs-tool’s list output now shows also the file modification time.
D.2 Problems fixed with this Release
Issue P00119-464, cfs-tool uses the file timestamps when creating a filesystem image
cfs-tool uses the file timestamps when creating a filesystem image. Those timestamps are also set when extracting.
The additional option –deterministic could be used to set all timestamps in the image to 0.
D.3 Known Problems
Issue P00119-284, Duplicate file names are not handled by file system check
When an error occurs in the file system so that two (or more) files within one directory have the same name, the file
system check will not detect this. The second (and further) file(s) won’t be accessible - until the first one is deleted.
Note: This cannot happen during a regular operation. Duplicated file names will be rejected during file/directory
creation.
c Copyright 2019 5
All rights reserved.
SYSGO GmbH

382
docs-extracted/releasenotes/releasenotes-hwvirt-5.0.3.md Normal file
View file

@ -0,0 +1,382 @@
---
title: "Releasenotes Hwvirt 5.0.3"
source: "docs/releasenotes/releasenotes-hwvirt-5.0.3.pdf"
category: "releasenotes"
pages: 8
extracted: "2026-07-06T23:05:51.032623"
---
# Releasenotes Hwvirt 5.0.3
> Extracted from `docs/releasenotes/releasenotes-hwvirt-5.0.3.pdf` (8 pages).
> Figures, diagrams, and tables may not render accurately in plain text.
Release Notes
1 Product Release Information
Product Name: Hardware Virtualization for PikeOS 5.0
Release and Build Number: 5.0.3/D5879
Release Date: 20.08.2019
2 Introduction
This document contains the release notes for Hardware Virtualization for PikeOS 5.0, build D5879. The following sections
describe the release in detail and provide information that supplements the main documentation.
Users of previous releases should check section 3.3 for instructions on how to use existing data with this new release.
For further information refer to the hardware virtualization (hardware-virtualization.pdf) manual which has been updated.
3 Installation and Upgrade News
3.1 Installation
Please see the manual PikeOS Installation Guide for more details.
3.2 Release Features
3.2.1 TrustZone support removed
The TrustZone support has been removed starting with this version of Hardware Virtualization for PikeOS.
3.2.2 Changes in the P4Bus/VMM protocols
The P4Bus and VMM protocols used to communicate between guests and their Hardware Virtualization for PikeOS manager
has been updated and enhanced with this version of Hardware Virtualization for PikeOS.
As a consequence your guest P4Bus and VMM drivers must be updated to be compatible with this release. Please check
the hardware virtualization manual for more information.
3.3 Compatibility to Other Versions
Some configuration parameters have been renamed or removed in the components so it is recommended to update the
configuration files of your guests in your integration project.
4 Enhancements introduced by this release
4.1 Enhancements introduced by this Release
Issue P00101-16987, [HWVIRT] New parameter to select file accesses of a vmfile for p4bus devices
A new parameter was added in p4bus device component to select file accesses of a vmfile. The different accesses
c Copyright 2019 1
All rights reserved.
SYSGO GmbH
Release Notes
available are 0 = No Access, 1 = Read Only, 2 = Write Only, 3 = Read Write, 4 = Read Write Map. The user can now
easily configure device access from Codeo.
4.2 Problems fixed with this Release
None.
4.3 Known Problems
None.
5 Frequently Asked Questions
Answers to frequently asked questions (FAQ) and resolutions to known issues are updated on a regular basis. These are
available online at http://www.sysgo.com/support/
6 Updates and Support
Updates will be provided on https://www.sysgo.com/downloadserver/. Please login using your account as stated
on the delivery document. Product support is available online at http://www.sysgo.com/support/
c Copyright 2019 2
All rights reserved.
SYSGO GmbH
Release Notes
A Previous Release 5.0.2 S5804
A.1 Enhancements introduced by this Release
Issue P00101-12936, [HWVIRT] Policy violations by guest generates standard HM events
Each different guest error generates a standard Health Monitoring event. Theses errors can be managed by group
(by using filters) or individually. The group action is done first, groups are like filters to easily configure HM actions
to do in error case. If P4_HM_PAC_IGNORE is selected for the group and a manual configuration exists for the
error, the manual action will be done otherwise default action will be performed. If the error is tagged as fatal and all
configurations are set as P4_HM_PAC_IGNORE, the partition will be automatically shutdown.
Issue P00101-14199, SMMU driver does not manage correctly partition reboot.
SMMU driver free correctly page tables if partition is shutdown and tables are reallocate when the partition is restarted.
SMMU transactions are disabled during partition reboot.
Issue P00101-15149, Enhance Virtio Memory HWVIRT Exception handler configurability
The handler example can now be configured with several areas defined by:
• A Name: used for logging and for property file system organization.
• A Verbosity: used to log access to a particular area
• A Guest physical start address
• A Size in Bytes
• A type: NULL or Memory
Issue P00101-15420, P4Bus-vmnet multicast support
The p4bus-vmnet linux driver now properly support multicast when used with a PikeOS Driver supporting it.
Issue P00101-15932, [HWVIRT] Check for the state of a p4bus operation before executing it.
The state of a p4bus operation is not checked before executing it, without raising any error to the user. The
p4bus protocol shall check the status of the operation before executing it, and raise an event if the operation is
not ready. When an operation to be executed by the P4BUS is not ready, a Health Monitoring event is raised
(P4HWVIRT_E_MNG_P4BUS_INVAL_OP_STATUS).
Issue P00101-15933, [HWVIRT] P4BUS devices size can be greater than 32 bits
It is now possible to use a P4BUS device with a size greater than 2GB.
Issue P00101-16225, [HWVIRT]: P4Bus ioctl interface for linux user clarified with new headers
All p4bus defines and structures useful for Linux user have been extracted into a new driver header p4bus-vmchar.h.
Issue P00101-16307, Document Hypervisor Errors
The hardware-virtualization document now describes the hypervisor errors code, symptoms and possible root cause.
Issue P00101-16368, [HWVIRT] Rework the P4BUS stat interface.
P4BUS_IOCTL_STAT interface was reworked to support a size of 64 bits for each field. The structure is described in
documentation.
Issue P00101-16444, Make HWVIRT Hypervisor Kernel Driver available for PikeOS 4.2.3
The HWVIRT Hypervisor Kernel Driver can be integrated in a Cortex A5x BSP fusion project of PikeOS 4.2.3.
Issue P00101-16681, [HWVIRT] Manager supports now standard coding style
- Fix compiler warnings (strict) - Fix indentation - Fix headers
Issue P00101-16786, Linux Kernel 4.15 to 4.20 support
The p4bus drivers provided with PikeOS are now compatible with Linux kernel up to the version 4.20.
c Copyright 2019 3
All rights reserved.
SYSGO GmbH
Release Notes
Issue P00101-16797, [HWVIRT] Two compatibility matrix between PikeOS and ELinOS has been added to the
documentation
Two matrix has been added to the documentation to explain compatibility between PikeOS and ELinOS. One describes
the compatibility of P4BUS drivers included in ELinOS and the second one describes the compatibility of P4BUS
drivers included in PikeOS.
Issue P00101-16992, Change default KMEMSIZE in guest process component
The default value, i.e. the minimum value, of the thread info size (thrinfo_size) as doubled. This led to an increase of
the memory consumption of the Hardware Virtualization. The solution has been to increase the default value of the
Kernel Memory Size (KMEM) in the Guest process component.
Issue P00101-17027, [HWVIRT] Add original return code of the PikeOS driver in vmchar IOCTL
A field containing the original return code of the PikeOS driver was added in the P4bus IOCTL native structure in the
vmchar IOCTL API. The documentation has been modified accordingly.
Issue P00101-17044, [HWVIRT] vmblock p4bus linux driver automatically uses the good IOCTL api version by
getting the block api version.
To use the right PikeOS driver API, vmblock p4bus linux driver check the block device API version during the open of
the device to automatically use the good IOCTL API.
A.2 Problems fixed with this Release
Issue P00101-14486, HWVIRT: Impossible to map non contiguous shared memory
The manager is now supporting mmap operations with non contiguous shared memory on guest.
Issue P00101-15092, Linux Kernel 4.14 support
The p4bus drivers provided with PikeOS are now compatible with Linux kernel up to the version 4.14.
Issue P00101-15169, HWVIRT: Impossible to map shared memory without cache attribute
The manager is now supporting all SHM types (cache and non cached) for mmap operations on guest.
Issue P00101-15417, echo on /proc/vmapi looping infinitely
An echo command done on the /proc/vmapi entry of a Linux guest was looping due to an invalid return code. This is
fixed in the Linux P4Bus vmapi driver with this version of PikeOS.
Issue P00101-15418, Linux 4.14 supported by HWVIRT
The p4bus drivers now properly support Linux 4.14. The code was changed to properly support the Stack remapping
feature from the Linux kernel that is now activated by default on 4.14 and following Linux versions.
Issue P00101-15723, ARM hardware virtualization: virtual machine monitor misses preemption requests
In some scenarios, the virtual machine monitor may have missed a preemption request when the execution was
interrupted shortly before entering a virtual machine. In this case, the virtual machine executed until the next VM exit
before scheduling again. A new function p4_kernel_is_preempt_pending() was added for the virtual machine monitor
to check for pending preemption requests before entering a VM.
Issue P00101-15852, VMBLOCK driver not working with volume providers
vmblock didn’t get the proper size with PikeOS block drivers. The problem is now fixed in vmblock driver with an IOCTL
to get the size.
Issue P00101-16226, [HWVIRT] Configure script for ELinOS feature fails on Cygwin environment
The issue is that the rule file used to compile the p4bus features are not correctly installed when using Cygwin as host
environment. The rules are now correctly installed.
Issue P00101-16382, Binary not found in hwvirt-guest-pikeos Demo
The issue was coming from the bad path given in ’Filename’. Indeed, it was looking for a dom file which did not exist.
Fixed by : - modifying the Hardware Virtualization documentation and the readme of the hwvirt-guest-pikeos demo. -
fixing the path of guest application (64bit for armv8 and 32bit for armv7).
c Copyright 2019 4
All rights reserved.
SYSGO GmbH
Release Notes
Issue P00101-16405, [HWVIRT] Missing directio component in ls1046
Some Guest OS might need to access the FlexTimer and the TMU, which led to an error as there were no directio
components related to these devices. This issue has been fixed by adding the relevant direct IO configuration.
Issue P00101-16464, Manager: wrong documentation of virtio_handle
The documentation of virtio_handle did not correspond to the function. The description is now fixed.
Issue P00101-16569, Wrong faulty address is logged when a data abort is raised
It appears that on LS1046a-rd board the Hypervisor IPA Fault Address Register (hpfar_el2) is not always updated after
a data abort, and the hypervisor always forward directly the value of hpfar_el2 after a data abort. The problem has
been corrected by first checking the validity of the hpfar_el2 register with the Exception Syndrome Register, and by
translating the Guest Faulty Virtual Address to get the right IPA.
Issue P00101-16611, Wrong data abort decoding for aarch32 guest
For a aarch32 guest, when an ASR instruction is used to compute the origin address of a data abort, the decoding of
the instruction by the hypervisor is not implemented as expected and data abort information is wrong. ASR instruction
is now handled as expected by the hypervisor.
Issue P00101-16816, HWVIRT Hypervisor does not handle wrong configuration of GIC CPU and DIST
Hypervisor now uses default values when the configuration parameters are set to zero.
Issue P00101-16830, [HWVIRT] All necessary accesses are checked during probe function in p4bus drivers
All necessary accesses are checked during probe function in p4bus drivers. If a necessary access is not allowed the
driver return an EACCES error.
Issue P00101-16918, [HWVIRT] Fix Fusion name in project xml of bsp-pikeos-hwvirt
The name attribute of the Fusion element in the project.xml of the bsp-pikeos-hwvirt contains a space. Typo fixed.
Issue P00101-16963, [HWVIRT] Special User Zero register is not emulated by the hypervisor
The Context of a Guest might be corrupted as the XZR/WZR register is not handled during GIC load/store exception
decoding, The XZR/WZR register is now included in the Guest Context and set to zero.
A.3 Known Problems
None.
c Copyright 2019 5
All rights reserved.
SYSGO GmbH
Release Notes
B Previous Release 5.0.1.1 S5500
B.1 Enhancements introduced by this Release
None.
B.2 Problems fixed with this Release
None.
B.3 Known Problems
None.
c Copyright 2019 6
All rights reserved.
SYSGO GmbH
Release Notes
C Previous Release 5.0.1 S5440
C.1 Enhancements introduced by this Release
Issue P00101-10697, New Watchdog VMM Driver
A new VMM device has been added to have a watchdog managed by the manager for guests. This can be used
to monitor Linux or PikeOS guests by forcing them to refresh the watchdog. An action can be defined using Health
Monitoring (halt or reboot or ignore) to configure how to handle a guest that does not refresh the watchdog.
Issue P00101-13686, Exception Handler can be extended in the kernel
The Hardware Virtualization can now be extended in kernel drivers or PSP with external exception handlers.
Those handlers can do things like:
• handling IO errors to simulate hardware
• handling SMC instructions to simulate a firmware
• creating new communication system by extending the HVC exception handler
• handling access to forbidden cpu registers (cp15 or msr/mrs instructions) to simulate processor features not
accessibles to guest
• extend the exception handler to handle some unsupported exceptions, 2 examples are provided as kernel driver
demos.
The documentation of hardware virtualization has also been extended to include an API documentation for functions
available to external exception handlers.
You can check the hardware virtualization documentation for more information.
Issue P00101-14186, Update of p4bus/vmm linux drivers
The p4bus/vmm drivers for linux guest have been upgraded:
• optimize ioring usage in network driver (to reduce manager thread usage during init)
• optimize network performances, better handing of race conditions
• add a vmm-watchdog driver
• cleanup tty and vmchar driver code
C.2 Problems fixed with this Release
Issue P00101-14340, MSR exception result not reported to guest
MSR exceptions handled by the manager or an external exception handler are now properly updating the guest context
with the value returned with the exception.
Issue P00101-14605, P4Bus Linux driver fixed to compile with newer GCC version
The P4Bus Linux drivers have been fixed to handle warning coming from newer gcc versions due to wrong indentation.
Issue P00101-15114, [HWVIRT] Wrong Core redirection of interrupts
A bug has been solved which made interrupts redirected on guest core 0 even though the interrupt cpu mask was not
set to 1 by the guest.
C.3 Known Problems
None.
c Copyright 2019 7
All rights reserved.
SYSGO GmbH
Release Notes
D Previous Release 5.0 S5319
D.1 Enhancements introduced by this release
Issue P00101-13719, KDEV: per-CPU initialization callback
The init_drv_cpu callback allows kernel drivers to perform a per-CPU setup at init time. The callback is called on each
CPU after the context of the idle thread of the CPU has already been setup, after the other initialization callbacks have
been invoked.
D.2 Problems fixed with this release
None.
D.3 Known Problems
Issue P00101-14232, HWVIRT guest devices are mapped without executable rights
Direct-IO guest devices are mapped uncacheable but the XN bit is currently not set in the hypervisor MMU configu-
ration. If a guest is running without MMU configured or without the XN bit set for devices mapping, this might lead to
random guest asynchronous aborts if the speculative instruction fetch is trying to pre-load from a device area.
Issue P00101-14340, MSR exception result not reported to guest
When an MSR exception is handled by the manager or an external exception handler, the guest register is not properly
updated with the returned value. To workaround this issue the context must be updated manually by the handler.
c Copyright 2019 8
All rights reserved.
SYSGO GmbH

6500
docs-extracted/releasenotes/releasenotes-pikeos-5.0.3.md Normal file
View file

File diff suppressed because it is too large Load diff

897
docs-extracted/releasenotes/releasenotes-posix-5.0.3.md Normal file
View file

@ -0,0 +1,897 @@
---
title: "Releasenotes Posix 5.0.3"
source: "docs/releasenotes/releasenotes-posix-5.0.3.pdf"
category: "releasenotes"
pages: 16
extracted: "2026-07-06T23:05:51.214209"
---
# Releasenotes Posix 5.0.3
> Extracted from `docs/releasenotes/releasenotes-posix-5.0.3.pdf` (16 pages).
> Figures, diagrams, and tables may not render accurately in plain text.
Release Notes
1 Product Release Information
Product Name: POSIX for PikeOS 5.0
Release and Build Number: 5.0.3/D5879
Release Date: 20.08.2019
2 Introduction
This document contains the release notes for POSIX for PikeOS 5.0, build D5879. The following sections describe the
release in detail and provide information that supplements the main documentation.
Users of previous releases should check section 4.3 for instructions on how to use existing data with this new release.
3 What’s New?
The POSIX operating system code was updated in several areas to adapt to changes made to the PikeOS kernel and PSSW.
Feature deprecation note: In this release the PikeOS POSIX Personality still includes support for the Instrumon function
which exports status information of the process to a shared memory object. Support for Instrumon and the Instrumon API for
monitoring applications will be removed in future versions of the product.
4 Installation and Upgrade News
4.1 Installation
Please see the manual PikeOS Installation Guide for more details.
4.2 Release Features
This release consists of the following components:
• POSIX Personality for PikeOS
• PikeOS Personality Manual: POSIX
• TCP/IP for PikeOS POSIX
• C++ support for PikeOS POSIX
The contents of the PikeOS POSIX: SMP document are now included in PikeOS Personality Manual: POSIX .
4.3 Compatibility to Other Versions
Rebuild all application programs using the POSIX headers and libraries. Update application and integration projects with the
new project configuration tools. Refer to section Project Migration Guidelines in the CODEO User Manual and the following
section in this document for project migration information.
c Copyright 2019 1
All rights reserved.
SYSGO GmbH
Release Notes
4.3.1 Notable Changes in the POSIX Process Component
The configuration parameter for the binary origin of a POSIX process was renamed from RFS_FILE to PIKFILE in order
to match other components in the PikeOS product (P00101-17106). If parameter RFS_FILE was used in your integration
project, change the parameter name to the new name or delete its use from project.xml and use the project configuration
tools to set the parameter as needed.
Changes made to the storage allocation for condition variables and synchronization objects made the corresponding config-
uration parameters for object pre-allocation obsolete (P00101-17016). In the POSIX process configuration tuneable param-
eters PARAMS_NOBJ_SYNC and PARAMS_NOBJ_CV have been removed. If your integration project used those parameters,
delete their use from project.xml.
Changes made to the storage allocation for condition variables and synchronization objects resulted in the removal of infor-
mation on such objects from the Instrumon image. In the POSIX process component, Instrumon configuration parameters
INSTR_SYNC and INSTR_CV have been removed (P00101-17015). If your integration project used those parameters, delete
their use from project.xml.
As a consequence of changes made to storage allocation for synchronization objects and the definition of the sem_t type,
tuneable parameter PARAMS_NSEMAPHORE (field num_of_semaphores in struct _configurables) now controls the number of
named semaphores (P00101-17011).
The names of queuing ports used by the Instrumon data access driver are now derived from the process name (P00101-
16737). Adapt channel definitions in the integration project as needed.
The names of queuing ports used by the Monitor device driver are now derived from the process name (P00101-15938).
Adapt channel definitions in the integration project as needed.
4.3.2 Notable Changes to the API and Implementation Internals
The base type for the definition of time_t is now a signed 64-Bit integer (P00101-9818). Application code making assumptions
on the nature of time_t should be checked for compatibility with the new base type.
Changes made to the storage allocation for condition variables and synchronization objects made the corresponding config-
uration parameters for object pre-allocation obsolete (P00101-17016). Structure fields init_sync_objects and init_cv_objects
have been removed from struct _configurables (defined in <sys/posix_config.h>). Adapt application code accessing
those fields as needed.
Changes made to the storage allocation for condition variables and synchronization objects resulted in the removal of
information on such objects from the Instrumon image and the Instrumon API for monitoring applications (P00101-17015).
Applications making use of the Instrumon API should be adapted as needed.
The lwip-build project can now be used to install a customized lwIP library in the custom pool (P00101-13278).
Object file crt0.o is now part of libpse51.a (P00101-16767). If your application project is not using the standard PikeOS
build process, adapt to the change as needed.
5 Recent User Visible Changes
5.1 Version Identifier
The version identifier __PikeOS_PSE51_version defined in <sys/param.h> for this release is set to 502000.
5.2 Enhancements introduced by this Release
None.
c Copyright 2019 2
All rights reserved.
SYSGO GmbH
Release Notes
5.3 Problems fixed with this Release
Issue P00101-17569, Threads created do not start with POSIX_SMP
A problem in POSIX_SMP where threads created with pthread_create() would fail to start when their thread affinity is
set to cores other than the one executing the call to pthread_create() has been fixed.
Issue P00101-17629, pthread_join() returns normally when caller gets canceled
Fixed a problem where a thread blocked in pthread_join() would return normally from that call even though a cancela-
tion request was posted to the thread.
5.4 Known Problems
Issue P00101-1402, _exit() does not close all open file descriptors
Functions _Exit() and exit() do not close open file descriptors.
Note that file associations with PSSW resources or external file providers will be closed by the PSSW when the
process’ partition is going to idle state.
Issue P00101-1759, Fatal exceptions when stepping through implementation with debugger
Applications may run into unexpected exceptions in native PikeOS threads used internally in the implementation (e.g.
ticker thread, device driver threads) when the debugger is instructed to step through API calls or step over complex
function-like macros containing such calls (for example custom trace event macros).
This mode of operating the debugger is currently not supported and should be avoided. Users should issue commands
to step over subroutine calls (using GDB’s ’next’ command) whenever an API call is reached.
Issue P00101-2015, close() is blocked by pending I/O
When close() is called on a file descriptor and there are other ongoing I/O operations pending on that descriptor, the
thread issuing the close() call will be blocked until all pending I/O operations finish before the close method of the
underlying file system provider is called.
Issue P00101-3130, Layout of ’stack_t’ not standard conforming
The definition of type stack_t in <signal.h> is currently not conforming to the POSIX standard.
Issue P00101-3234, Math is not IEEE-754 compliant on E500 platforms
Quoting Freescale SPEPEM Rev.0 01/2008 Section 3.3.1.4 IEEE Std 754 Compliance
The embedded floating-point categories require a floating-point system as defined in IEEE 754 but may rely on
software support in order to conform fully with the standard. Thus, whenever an input operand of the embedded
floating-point instruction has data values that are +infinity, -infinity, denormalized, NaN, or when the result of an
operation produces an overflow or an underflow, an embedded floating-point data interrupt may be taken and the
interrupt handler is responsible for delivering IEEE 754-compliant behavior if desired.
Issue P00101-7314, Message queue notifications could cause a memory leak
Pending message queue notifications are not deleted when a message queue is deleted, for example some
SIGEV_SIGNAL notifications are produced as a result of putting some messages into a message queue remain
pending even if that message queue is closed and unlinked.
Note that descriptors for message queue notifications are dynamically allocated from heap memory and are put on a
free list after consumption but released back to the memory heap.
Issue P00101-8393, [lwIP] Socket API is not thread-safe
The lwIP socket API is not thread-safe. Simultaneous operations on the same socket from multiple threads may lead
to undefined behavior. Using multiple threads operating each on a separate socket is supported.
Issue P00101-10431, mktime() fails to indicate conversion errors
For certain input data that is not representable in a time_t object, function mktime() fails to return (time_t)-1 to indicate
the error.
c Copyright 2019 3
All rights reserved.
SYSGO GmbH
Release Notes
Issue P00101-13658, accept() causes failed assertion when used on datagram socket
With an lwIP network stack configured for TCP and UDP support (the default configuration), calling accept() with a
datagram socket will cause a failed assertion (if enabled) in the lwIP network stack. If assertion checks are not enabled
in the stack, accept() will fail to indicate an error to the caller when used on a datagram socket.
6 Frequently Asked Questions
Answers to frequently asked questions (FAQ) and resolutions to known issues are updated on a regular basis. These are
available online at http://www.sysgo.com/support/
7 Updates and Support
Updates will be provided on https://www.sysgo.com/downloadserver/. Please login using your account as stated
on the delivery document. Product support is available online at http://www.sysgo.com/support/
c Copyright 2019 4
All rights reserved.
SYSGO GmbH
Release Notes
A Previous Release 5.0.2 S5804
A.1 Enhancements introduced by this Release
Issue P00101-8655, <fenv.h> services with external linkage
Services previously only defined as inline functions by <fenv.h> are now provided as functions with external linkage,
so they can be used without including the associated header.
Issue P00101-9818, 64-bit time_t
The time_t type is now a signed 64-bit integer. Refer to section ’Time and Timeouts’ in the PikeOS/POSIX personality
manual for further details.
Issue P00101-12778, mmap() for ROM file system and generic PikeOS resource access
The use of the MAP_FIXED flags in calls for mmap() is no longer required for files associated with the generic PikeOS
file system provider (i.e /ssw/ pathname prefix).
mmap() is now supported for the ROM file system provider (i.e. /rfs/ pathname prefix).
Issue P00101-13278, Customized lwIP library changes
The lwip-build project has been modified to allow installation of the customized lwIP library to the custom pool. The
build process of applications configured for lwIP network support will now search for lwIP components located in the
custom pool before falling back to the components in the PikeOS pool. Application project options POSIX_LWIP_CUS-
TOM and POSIX_LWIP_LIB_DIR can still be used to forcibly set the location of the lwIP library, in this case the custom
pool is not taken into consideration during the build.
Furthermore the lwip-build template now includes source code to the interface between lwIP and the POSIX file system
layer and lwIP configuration property handling.
Issue P00101-13898, std::atexit added to C++98
The C++98 implementation for the POSIX personality now includes std::atexit.
Issue P00101-14286, Support for long double in formatted I/O functions
The printf- and scanf-family of functions now support conversions for the long double data type. Furthermore functions
strtold() and wcstold() have been added to the API.
Issue P00101-14381, Pathname length in trace events
The length of filenames and pathnames in trace event attributes has been increased to 255 bytes. This change may
affect the stack usage in trace-enabled configurations.
Issue P00101-14932, New signal handling trace events
Leaving a signal handling function through normal return or non-local goto can now be observed through trace events.
Issue P00101-15504, Trace support for times(), clock(), and pthread_getcputime_np()
Function times(), clock(), and pthread_getcputime_np() can now be observed in the CODEO trace tool.
Issue P00101-15738, Support EABI
Adaptations have been made to allow PikeOS components to be EABI compatible.
Issue P00101-15938, Name of Monitor driver queuing ports changed
The names of the queuing ports used by the Monitor driver are now derived from the process name allowing multiple
processes in the same partition to use the Monitor driver with queuing ports as I/O channel. The input port name is
<process-name>-monrx, the output port name is <process-name>-montx.
Issue P00101-16162, Trace support for sysconf()
Use of function sysconf() can now be observed in the CODEO trace tool.
Issue P00101-16185, Trace support for SMP API additions
The following functions can now be observed in the CODEO trace tool.
• pthread_attr_getaffinity_np()
c Copyright 2019 5
All rights reserved.
SYSGO GmbH
Release Notes
• pthread_attr_setaffinity_np()
• pthread_getaffinity_np()
• pthread_setaffinity_np()
• pthread_getcpu_np()
• pthread_getnumcpu_np()
A trace event for observing thread CPU migration has been added to scheduling event group. the
Issue P00101-16297, Tracing of main() argument vector
The contents of the argument vector passed to the main() function can now be observed in the CODEO trace tool.
Issue P00101-16553, PPC: set MSR.FE0 and FE1 when enabling FPU for a thread
When creating a thread with P4_THREAD_ARG_FPU flag, or when calling p4_thread_fpu_on(), the FE0 and FE1 bits
in MSR are now set by default.
FPU exceptions remain disabled as FPSCR is initialized to zero. However, user space code can enable FPU excep-
tions by modifying these bits in FPSCR directly.
Issue P00101-16737, Name of Instrumon data access queuing ports changed
The names of the queuing ports used by the Instrumon data access driver are now derived from the process name
allowing multiple processes in the same partition to use the data access driver. The input port name is <process-
name>-instr_rx, the output port name is <process-name>-instr_tx.
Issue P00101-16767, Module crt0.o is now part of libpse51.a
The object module containing the program entry point (crt0.o) is now part of libpse51.a. Application projects not using
the standard PikeOS build environment to create executable programs might need to be adapted accordingly.
Issue P00101-16837, pthread_once() exit trace event
The pthread_once() function exit trace event now also includes the address of the pthread_once_t object.
Issue P00101-16838, Trace event for thread-specific data key destructor function
Trace events are now emitted for each invocation of a thread-specific data key destructor function. The envent
attributes include the key value, function address, and function argument.
Issue P00101-16849, readdir_r() trace event enhancement
The function exit trace events for readdir_r() now include the file name as event attribute.
Issue P00101-16884, Function strndup() added
Function strndup() was added to the C library of the PikeOS POSIX Personality. The function is equivalent to strdup()
but allows the caller to specify a maximum number of bytes in the source string to duplicate.
Issue P00101-16961, Storage for Pthread API attributes objects
Storage space for attributes objects used in the Pthread API (i.e. pthread_attr_t, pthread_condattr_t,
pthread_mutexattr_t, and pthread_rwlockattr_t) will now be explicitly allocated in the object definition instead of being
allocated from dynamic memory during calls to the respective object initialization function. The data types for attributes
objects were changed accordingly from object handles to data structures describing the object.
Issue P00101-16966, Thread CPU time accounting now a run-time configuration option
Since per-thread CPU time accounting adds significant overhead, the feature is now a run-time configuration option.
By default the feature is disabled. Refer to the PikeOS Personality Manual: POSIX for further details.
Issue P00101-17011, Semaphore descriptor type change
Type sem_t is no longer defined as an object handle, it now defines a structure type. As a consequence of this change,
storage for unnamed semaphores is explicitly allocated in the application program. Storage for named semaphores
will still be allocated by the operating system when sem_open() is called. Tuneable parameter PARAMS_NSEMAPHORE
(field num_of_semaphores in struct _configurables) now controls the number of named semaphores available to the
application.
c Copyright 2019 6
All rights reserved.
SYSGO GmbH
Release Notes
Issue P00101-17015, Instrumon API changes
Changes made to the storage allocation for condition variables and synchronization objects resulted in the removal of
information on such objects from the Instrumon image and the Instrumon API for monitoring applications. In the POSIX
process definition, parameters INSTR_SYNC and INSTR_CV have been removed. In the Instrumon API for monitoring
applications, functions accessing information on synchronization objects (instr_sync_XXX() and type instr_sync_t) or
condition variables (instr_condvar_XXX() and type instr_condvar_t) have been removed. Types instr_proc_stat_t and
instr_app_config_t were updated accordingly, fields for the number of allocated and in use synchronization objects
and condition variables have been removed.
Issue P00101-17016, Storage for condition variables and synchronization objects
Storage space for condition variables (pthread_cond_t) and synchronization objects (pthread_mutex_t and
pthread_rwlock_t) will now be explicitly allocated in the object definition instead of being allocated from dynamic
memory during calls to the respective object initialization function. The data types for such objects were changed ac-
cordingly from object handles to data structures describing the object. Tuneable parameters PARAMS_NOBJ_SYNC
(field init_sync_objects in struct _configurables) and PRAMS_NOBJ_CV (field init_cv_objects in struct _configurables)
are obsolete with this change and have been removed.
Issue P00101-17106, Parameter name change in POSIX process component
The name of the parameter specifying the PikeOS pathname of the process image was changed from RFS_FILE to
PIKFILE to match the naming in other PikeOS components.
A.2 Problems fixed with this Release
Issue P00101-14817, x86_i686: Library code may invoke callbacks without properly aligned stack
Library code (e.g. vm_fp_listen() in LIBVM) was compiled with the compiler option -mpreferred-stack-bounary=2 and
might have invoked callbacks without ensuring the 16-byte stack alignment required by the ABI. The compiler option
was removed and libraries now ensure 16-byte alignment of the stack when invoking callbacks.
Issue P00101-15467, Use of <stddef.h> in C++ triggers -Wundef warning
Fixed an issue with a -Wundef warning being raised when including file <stddef.h> in C++ code.
__PikeOS_PSE51_version has been set to 402003 to indicate the change.
Issue P00101-15644, Run queue corruption when changing priority of active thread on other core
A problem that could lead to corruption of internal administrative data structures of the application thread sched-
uler on POSIX_SMP when changing the scheduling priority of an active thread using pthread_setschedparam() or
pthread_stetschedpriority() has been fixed.
__PikeOS_PSE51_version has been set to 402003 to indicate the change.
Issue P00101-15648, Incorrect file type for shared memory objects
A problem with an incorrect file type encoded in the st_mode field of the stat structure obtained from a call to fstat() on
a file descriptor opened with shm_open() has been fixed.
__PikeOS_PSE51_version has been set to 402003 to indicate the change.
Issue P00101-15797, dd_iomem_set_attr() fails with EIO
In a process without VM_AB_CACHE_CHANGE ability attempts to modify cache attributes using dd_iomem_set_attr()
will now fail with EPERM error indication.
Issue P00101-15802, Partition mode change with dd_os_control() fails with EIO
In calls to dd_os_control() requesting partition mode change operations that lead to the underlying
vm_part_set_mode() call to fail with P4_E_STATE, the corresponding dd_os_control() call will now indicate EIN-
PROGRESS.
__PikeOS_PSE51_version has been set to 402003 to indicate the change.
Issue P00101-15861, Failed assertion when creating a SOCK_RAW type socket
Function socket() will not fail with ENOBUFS when attempting to create a socket for a disabled domain (for example a
raw socket with a stack configured with LWIP_RAW=0).
c Copyright 2019 7
All rights reserved.
SYSGO GmbH
Release Notes
Issue P00101-15981, Compile erorr with <sys/qport.h>
Fixed a compile error with <sys/qport.h> when type size_t is not defined.
Issue P00101-15991, feholdexcept() saves incorrect floating-point environment data
Fixed a problem with function feholdexcept() saving incorrect floating-point environment data on PowerPC architec-
tures with classical FPU has been fixed.
Issue P00101-16120, lwIP: select() ignores the nfds parameter
A problem with the select() implementation in the interface to the lwIP network stack ignoring the first argument passed
in the call to the function (nfds) has been fixed.
Issue P00101-16131, timespec::tv_nsec values truncated in trace events on 64-bit architectures
Fixed a problem with truncated values of the tv_nsec field of the timespec structure in trace events on 64-bit architec-
tures.
Issue P00101-16634, Issues with strtod()
Problems with strtod() not indicating range errors on exponent overflow and not indicating invalid input for empty strings
have been fixed.
Issue P00101-16696, Health monitor error during exit processing
A problem with programs raising n ’E17:static mutex’ health monitor error during exit() processing has been fixed.
Issue P00101-16825, Application errors lead to failed assertions in lwIP network stack
A problem with application errors in calls to network API services leading to failed assertions in the lwIP network stack
implementation instead of API services failing gracefully has been fixed.
Issue P00101-16853, Incorrect file names returned by readdir_r()
A problem with readdir_r() returning incorrect file names in the dirent::d_name field when used on volume providers or
on remote file systems accessed with the NFS client option has been fixed.
Issue P00101-16880, dd_create_thread_mc() does not inherit affinity mask
Fixed a problem with function dd_create_thread_mc() causing a segmentation fault when called with the null pointer
as ’cpu_mask’ argument. When called in SMP configurations, function dd_create_thread() will now create a device
driver thread with CPU affinity mask inherited from the calling application thread.
Issue P00101-17078, Incorrect FLT_EVAL_METHOD value in arm_v7hf and x86_amd64
The definition of symbol FTL_EVAL_METHOD has been corrected to expands as 0 (zero) for arm_v7hf and
x86_amd64.
Issue P00101-17290, Race condition in pthread_join()
A problem with multiple simultaneous calls to pthread_join() on the same target thread leaving joiners suspended in
JOIN_WAIT waiting for an already exited and detached thread has been fixed.
Issue P00101-17370, Unblocking of threads upon timeout of pthread_rwlock_timedwrlock()
A problem with threads blocked on a read-write lock object not being unblocked after a previous attempt to lock the
object for writing using pthread_rwlock_timedwrlock() failing with a timeout has been fixed.
A.3 Known Problems
Issue P00101-1402, _exit() does not close all open file descriptors
Functions _Exit() and exit() do not close open file descriptors.
Note that file associations with PSSW resources or external file providers will be closed by the PSSW when the
process’ partition is going to idle state.
Issue P00101-1759, Fatal exceptions when stepping through implementation with debugger
Applications may run into unexpected exceptions in native PikeOS threads used internally in the implementation (e.g.
ticker thread, device driver threads) when the debugger is instructed to step through API calls or step over complex
function-like macros containing such calls (for example custom trace event macros).
c Copyright 2019 8
All rights reserved.
SYSGO GmbH
Release Notes
This mode of operating the debugger is currently not supported and should be avoided. Users should issue commands
to step over subroutine calls (using GDB’s ’next’ command) whenever an API call is reached.
Issue P00101-2015, close() is blocked by pending I/O
When close() is called on a file descriptor and there are other ongoing I/O operations pending on that descriptor, the
thread issuing the close() call will be blocked until all pending I/O operations finish before the close method of the
underlying file system provider is called.
Issue P00101-3130, Layout of ’stack_t’ not standard conforming
The definition of type stack_t in <signal.h> is currently not conforming to the POSIX standard.
Issue P00101-3234, Math is not IEEE-754 compliant on E500 platforms
Quoting Freescale SPEPEM Rev.0 01/2008 Section 3.3.1.4 IEEE Std 754 Compliance
The embedded floating-point categories require a floating-point system as defined in IEEE 754 but may rely on
software support in order to conform fully with the standard. Thus, whenever an input operand of the embedded
floating-point instruction has data values that are +infinity, -infinity, denormalized, NaN, or when the result of an
operation produces an overflow or an underflow, an embedded floating-point data interrupt may be taken and the
interrupt handler is responsible for delivering IEEE 754-compliant behavior if desired.
Issue P00101-7314, Message queue notifications could cause a memory leak
Pending message queue notifications are not deleted when a message queue is deleted, for example some
SIGEV_SIGNAL notifications are produced as a result of putting some messages into a message queue remain
pending even if that message queue is closed and unlinked.
Note that descriptors for message queue notifications are dynamically allocated from heap memory and are put on a
free list after consumption but released back to the memory heap.
Issue P00101-8393, [lwIP] Socket API is not thread-safe
The lwIP socket API is not thread-safe. Simultaneous operations on the same socket from multiple threads may lead
to undefined behavior. Using multiple threads operating each on a separate socket is supported.
Issue P00101-10431, mktime() fails to indicate conversion errors
For certain input data that is not representable in a time_t object, function mktime() fails to return (time_t)-1 to indicate
the error.
Issue P00101-13658, accept() causes failed assertion when used on datagram socket
With an lwIP network stack configured for TCP and UDP support (the default configuration), calling accept() with a
datagram socket will cause a failed assertion (if enabled) in the lwIP network stack. If assertion checks are not enabled
in the stack, accept() will fail to indicate an error to the caller when used on a datagram socket.
Issue P00101-16821, Limited support of <atomic>
Support for atomic operations (in C++11) is based on compiler builtins, functions usually found in libatomic.a are
currently not implemented. This may result in unresolved references in the link stage when using certain services
from <atomic> or when using std::atomic on larger compound types that are unsuitable for atomic operation compiler
builtins.
c Copyright 2019 9
All rights reserved.
SYSGO GmbH
Release Notes
B Previous Release 5.0.1.1 S5500
B.1 Enhancements introduced by this Release
None.
B.2 Problems fixed with this Release
None.
B.3 Known Problems
Issue P00101-1402, _exit() does not close all open file descriptors
Functions _Exit() and exit() do not close open file descriptors.
Note that file associations with PSSW resources or external file providers will be closed by the PSSW when the
process’ partition is going to idle state.
Issue P00101-1759, Fatal exceptions when stepping through implementation with debugger
Applications may run into unexpected exceptions in native PikeOS threads used internally in the implementation (e.g.
ticker thread, device driver threads) when the debugger is instructed to step through API calls or step over complex
function-like macros containing such calls (for example custom trace event macros).
This mode of operating the debugger is currently not supported and should be avoided. Users should issue commands
to step over subroutine calls (using GDB’s ’next’ command) whenever an API call is reached.
Issue P00101-2015, close() is blocked by pending I/O
When close() is called on a file descriptor and there are other ongoing I/O operations pending on that descriptor, the
thread issuing the close() call will be blocked until all pending I/O operations finish before the close method of the
underlying file system provider is called.
Issue P00101-3130, Layout of ’stack_t’ not standard conforming
The definition of type stack_t in <signal.h> is currently not conforming to the POSIX standard.
Issue P00101-3234, Math is not IEEE-754 compliant on E500 platforms
Quoting Freescale SPEPEM Rev.0 01/2008 Section 3.3.1.4 IEEE Std 754 Compliance
The embedded floating-point categories require a floating-point system as defined in IEEE 754 but may rely on
software support in order to conform fully with the standard. Thus, whenever an input operand of the embedded
floating-point instruction has data values that are +infinity, -infinity, denormalized, NaN, or when the result of an
operation produces an overflow or an underflow, an embedded floating-point data interrupt may be taken and the
interrupt handler is responsible for delivering IEEE 754-compliant behavior if desired.
Issue P00101-7314, Message queue notifications could cause a memory leak
Pending message queue notifications are not deleted when a message queue is deleted, for example some
SIGEV_SIGNAL notifications are produced as a result of putting some messages into a message queue remain
pending even if that message queue is closed and unlinked.
Note that descriptors for message queue notifications are dynamically allocated from heap memory and are put on a
free list after consumption but released back to the memory heap.
Issue P00101-8393, [lwIP] Socket API is not thread-safe
The lwIP socket API is not thread-safe. Simultaneous operations on the same socket from multiple threads may lead
to undefined behavior. Using multiple threads operating each on a separate socket is supported.
Issue P00101-10431, mktime() fails to indicate conversion errors
For certain input data that is not representable in a time_t object, function mktime() fails to return (time_t)-1 to indicate
the error.
c Copyright 2019 10
All rights reserved.
SYSGO GmbH
Release Notes
Issue P00101-13658, accept() causes failed assertion when used on datagram socket
With an lwIP network stack configured for TCP and UDP support (the default configuration), calling accept() with a
datagram socket will cause a failed assertion (if enabled) in the lwIP network stack. If assertion checks are not enabled
in the stack, accept() will fail to indicate an error to the caller when used on a datagram socket.
Issue P00101-14817, x86_i686: Library code may invoke callbacks without properly aligned stack
Library code is compiled with the compiler option -mpreferred-stack-bounary=2 and may invoke callbacks without
ensuring the 16-byte stack alignment required by the ABI.
Issue P00101-15644, Run queue corruption when changing priority of active thread on other core
Changing the scheduling priority using pthread_setschedparam() or pthread_stetschedpriority() of an active thread
currently running on another CPU in POSIX_SMP leads to corruption of internal administrative data structures of the
application thread scheduler. The corruption may either cause application hangups or raising of POSIX operating
system panic errors in subsequent service calls.
c Copyright 2019 11
All rights reserved.
SYSGO GmbH
Release Notes
C Previous Release 5.0.1 S5440
C.1 Enhancements introduced by this Release
Issue P00101-12737, Introduce P4_HM_TYPE_PERSONALITY
The P4_HM_TYPEs:
• P4_HM_TYPE_POSIX
• P4_HM_TYPE_APEX
• P4_HM_TYPE_DDK
has been substituted by a single type P4_HM_TYPE_PERSONALITY indicating that an HM event refers to a PikeOS-
specific personality (e.g., APEX, POSIX).
Issue P00101-12782, CPU time accounting
Application thread and process CPU time accounting has been added to the implementation.
Function pthread_getcputime_np() can be used to retrieve the CPU time of an application thread. Furthermore
clock identifiers CLOCK_THREAD_CPUTIME_ID and CLOCK_PROCESS_CPUTIME_ID have been added. When
called with clock identifier CLOCK_THREAD_CPUTIME_ID function clock_gettime() can be used to retrieve the CPU
consumption of the thread calling the thread. Similarly, clock identifier CLOCK_PROCESS_CPUTIME_ID can be used
with clock_gettime() to retrieve CPU consumption of the process. Note that option _POSIX_THREAD_CPUTIME is
not fully implemented, CLOCK_PROCESS_CPUTIME_ID and CLOCK_THREAD_CPUTIME_ID cannot be used with
timer API functions.
The CPU time usage of application threads is also exported to the Instrumon image, if enabled.
Issue P00101-13616, Trace events for mount and unmount operations
Trace events for file system mount (_fs_add_fs()) and unmount (_fs_remove_fs()) operations have been added, the
events are located in the ’File System’ category.
Issue P00101-13701, times() function enhancement
Function times() now returns information on CPU time spent in application threads in tms::tms_utime and CPU
time spent in device driver threads and other internal threads of the implementation in tms::tms_stime. As the
implementation is a single-process environment, the values tms::tms_cutime and tms::tms_cstime are set to zero.
The return value of the times() function is the number of elapsed clock ticks since the start of the process. All times
returned in the tms structure are measured in clock ticks. The number of clock ticks per second can be retrieved using
sysconf(_SC_CLK_TCK).
If any of the fields in the tms structure or the function return value would overflow, the function fails with errno set to
EOVERFLOW.
Issue P00101-13736, Function clock()
Function clock() has been added to the implementation. Symbol CLOCKS_PER_SEC is defined by <time.h> with a
value of one million, a value that is aligned with other commonly used systems.
Issue P00101-13901, Functions dprintf() and vdprintf() added
Functions dprintf() and vdprintf() from the POSIX_DEVICE_IO_EXT option group have been added. The functions are
declared as follows:
\#include <stdio.h>
\#include <stdarg.h>
int dprintf(int fildes, const char *restrict format, ...);
int vdprintf(int fildes, const char *restrict format, va\_list ap);
c Copyright 2019 12
All rights reserved.
SYSGO GmbH
Release Notes
The dprintf() function is equivalent to the fprintf() function, except that dprintf() writes output to a file descriptor specified
as function argument rather than place output on a stream. Function vdprintf() is equivalent to dprintf(), except that
instead of being called with a variable number of arguments, it is called with an argument list as defined by <stdarg.h>.
Issue P00101-14246, Extension functions for formatted error messages
Convenience functions to format error messages have been added to the implementation. Refer to the descrip-
tion of functions err(), verr(), errc(), verrc(), errx(), verrx(), warn(), vwarn(), warnc(), vwarnc(), warnx(), vwarnx(),
err_set_exit(), and err_set_file() in the personality manual for further details.
Issue P00101-14248, Functions stpcpy() and stpncpy() added
The implementation now includes functions stpcpy() and stpncpy() that appeared in the POSIX_C_LIB_EXT option
group in IEEE Std. 1003.1-2008.
Issue P00101-14679, Type change in configuration property
Configuration tuneable parameters _configurables::heap_size (property path ’config/heap/heap_size’) and _config-
urables::heap_pool_chunk (property path ’config/heap/heap_pool_chunk’) are now of type size_t (property type
prop_size).
Issue P00101-15220, CPU mask fields in dd_os_part_info_t
The dd_os_part_info_t type includes two new fields that contain resource and time partition CPU mask that are valid
for the process. Command code DD_OS_PART_INFO of function dd_os_control() will return this data. Refer to the
personality manual and the description of type vm_partition_stat_t in the system software reference manual for further
details.
C.2 Problems fixed with this Release
Issue P00101-13505, Unsupported file creation flags for mount_vp()
File creation flags O_CREAT and O_TRUNC have no meaning in calls to mount_vp(). File creation and truncation is
controlled by permissions to write to the volume.
Issue P00101-14204, Base type of clock_t
Type clock_t is now consistently defined as unsigned long for all architectures.
Issue P00101-14228, Incomplete decoding of memory requirement cache mode attributes
Enumeration types prop_mem_cache_t and dd_vmit_cachemode_t as well as field cachemode in structure
type dd_vmit_mem_flags_t have been extended to be able to represent memory requirement cache modes
VM_MEM_CACHE_WC and VM_MEM_CACHE_DEV.
Issue P00101-14645, Size of administrative data in dynamic memory services
A change in the size of of administrative data used by dynamic memory allocation services on 64-bit architectures
may reduce the amount of memory available for applications. The change affects PikeOS native applications (regular,
non-cert variant), volume providers, and applications using the POSIX personality.
Issue P00101-14709, Failure to resume suspended threads in message queue operations with POSIX_SMP
A problem in the POSIX_SMP implementation that would prevent threads on one core blocked waiting for a message
queue to be scheduled when a thread on another core changes the state of that message queue has been fixed.
Issue P00101-14735, Incorrect return value of large read() and write() on PikeOS resources
A problem with read() and write() returning incorrect values for successful requests larger than 2GB on file descriptors
associated with PikeOS volume providers or PikeOS resources accessed through the ’/rfs/’ and ’/ssw/’ pathname
prefixes has been fixed.
Issue P00101-15249, C++98 not built with threads support
A problem in the build configuration of the C++98 implementation for the PikeOS POSIX personality that effectively
disabled multi-thread support has been fixed.
c Copyright 2019 13
All rights reserved.
SYSGO GmbH
Release Notes
C.3 Known Problems
Issue P00101-1402, _exit() does not close all open file descriptors
Functions _Exit() and exit() do not close open file descriptors.
Note that file associations with PSSW resources or external file providers will be closed by the PSSW when the
process’ partition is going to idle state.
Issue P00101-1759, Fatal exceptions when stepping through implementation with debugger
Applications may run into unexpected exceptions in native PikeOS threads used internally in the implementation (e.g.
ticker thread, device driver threads) when the debugger is instructed to step through API calls or step over complex
function-like macros containing such calls (for example custom trace event macros).
This mode of operating the debugger is currently not supported and should be avoided. Users should issue commands
to step over subroutine calls (using GDB’s ’next’ command) whenever an API call is reached.
Issue P00101-2015, close() is blocked by pending I/O
When close() is called on a file descriptor and there are other ongoing I/O operations pending on that descriptor, the
thread issuing the close() call will be blocked until all pending I/O operations finish before the close method of the
underlying file system provider is called.
Issue P00101-3130, Layout of ’stack_t’ not standard conforming
The definition of type stack_t in <signal.h> is currently not conforming to the POSIX standard.
Issue P00101-3234, Math is not IEEE-754 compliant on E500 platforms
Quoting Freescale SPEPEM Rev.0 01/2008 Section 3.3.1.4 IEEE Std 754 Compliance
The embedded floating-point categories require a floating-point system as defined in IEEE 754 but may rely on
software support in order to conform fully with the standard. Thus, whenever an input operand of the embedded
floating-point instruction has data values that are +infinity, -infinity, denormalized, NaN, or when the result of an
operation produces an overflow or an underflow, an embedded floating-point data interrupt may be taken and the
interrupt handler is responsible for delivering IEEE 754-compliant behavior if desired.
Issue P00101-7314, Message queue notifications could cause a memory leak
Pending message queue notifications are not deleted when a message queue is deleted, for example some
SIGEV_SIGNAL notifications are produced as a result of putting some messages into a message queue remain
pending even if that message queue is closed and unlinked.
Note that descriptors for message queue notifications are dynamically allocated from heap memory and are put on a
free list after consumption but released back to the memory heap.
Issue P00101-8393, [lwIP] Socket API is not thread-safe
The lwIP socket API is not thread-safe. Simultaneous operations on the same socket from multiple threads may lead
to undefined behavior. Using multiple threads operating each on a separate socket is supported.
Issue P00101-10431, mktime() fails to indicate conversion errors
For certain input data that is not representable in a time_t object, function mktime() fails to return (time_t)-1 to indicate
the error.
Issue P00101-14817, x86_i686: Library code may invoke callbacks without properly aligned stack
Library code is compiled with the compiler option -mpreferred-stack-bounary=2 and may invoke callbacks without
ensuring the 16-byte stack alignment required by the ABI.
c Copyright 2019 14
All rights reserved.
SYSGO GmbH
Release Notes
D Previous Release 5.0 S5319
D.1 Enhancements introduced by this release
None.
D.2 Problems fixed with this release
None.
D.3 Known Problems
Issue P00101-1402, _exit() does not close all open file descriptors
Functions _Exit() and exit() do not close open file descriptors.
Note that file associations with PSSW resources or external file providers will be closed by the PSSW when the
process’ partition is going to idle state.
Issue P00101-1759, Fatal exceptions when stepping through implementation with debugger
Applications may run into unexpected exceptions in native PikeOS threads used internally in the implementation (e.g.
ticker thread, device driver threads) when the debugger is instructed to step through API calls or step over complex
function-like macros containing such calls (for example custom trace event macros).
This mode of operating the debugger is currently not supported and should be avoided. Users should issue commands
to step over subroutine calls (using GDB’s ’next’ command) whenever an API call is reached.
Issue P00101-1878, NFS client sends request from unprivileged ports
Due to limitations of the lwIP stack NFS servers must accept client requests originating from unprivileged port numbers
in PSE52 configurations.
NFS servers on Linux usually need the insecure option specified in the exports(5) file to enable this mode of operation,
on other systems it may be an explicit option which must be passed to mountd(8) during startup.
Issue P00101-2015, close() is blocked by pending I/O
When close() is called on a file descriptor and there are other ongoing I/O operations pending on that descriptor, the
thread issuing the close() call will be blocked until all pending I/O operations finish before the close method of the
underlying file system provider is called.
Issue P00101-3130, Layout of ’stack_t’ not standard conforming
The definition of type stack_t in <signal.h> is currently not conforming to the POSIX standard.
Issue P00101-3234, Math is not IEEE-754 compliant on E500 platforms
Quoting Freescale SPEPEM Rev.0 01/2008 Section 3.3.1.4 IEEE Std 754 Compliance
The embedded floating-point categories require a floating-point system as defined in IEEE 754 but may rely on
software support in order to conform fully with the standard. Thus, whenever an input operand of the embedded
floating-point instruction has data values that are +infinity, -infinity, denormalized, NaN, or when the result of an
operation produces an overflow or an underflow, an embedded floating-point data interrupt may be taken and the
interrupt handler is responsible for delivering IEEE 754-compliant behavior if desired.
Issue P00101-7314, Message queue notifications could cause a memory leak
Pending message queue notifications are not deleted when a message queue is deleted, for example some
SIGEV_SIGNAL notifications are produced as a result of putting some messages into a message queue remain
pending even if that message queue is closed and unlinked.
Note that descriptors for message queue notifications are dynamically allocated from heap memory and are put on a
free list after consumption but released back to the memory heap.
c Copyright 2019 15
All rights reserved.
SYSGO GmbH
Release Notes
Issue P00101-8393, [lwIP] Socket API is not thread-safe
The lwIP socket API is not thread-safe. Simultaneous operations on the same socket from multiple threads may lead
to undefined behavior. Using multiple threads operating each on a separate socket is supported.
Issue P00101-10431, mktime() fails to indicate conversion errors
For certain input data that is not representable in a time_t object, function mktime() fails to return (time_t)-1 to indicate
the error.
Issue P00101-11734, Missing declarations of API functions
Declarations of some API services documented in the personality manual are missing from their respective header
files. A possible workaround is to define preprocessor macro __BSD_VISIBLE to one, either prior to including a header
or on the compiler command-line. Note however, that this workaround may expose more declarations than those that
are actually supported by the implementation.
Issue P00101-12612, Failed assertions in device driver threads in debug configuration
Device driver threads created with dd_create_thread() or dd_create_thread_mc() that call PSE51 operating system
services that may trigger application thread re-scheduling may raise failed assertions leading to abnormal process
termination if the application was built with debug support enabled (POSIX_DEBUG=true).
From the set of system services that are allowed to be called from device driver context, the following services may
lead to the error:
• pthread_cond_signal()
• pthread_cond_broadcast()
• dd_process_clock()
• dd_process_clockn()
There is no workaround for the issue.
Configuration not enabled for debugging (POSIX_DEBUG=false) are not affected. The conditions leading to the failed
assertion checks do not negatively affect operation of the process.
Issue P00101-13658, accept() causes failed assertion when used on datagram socket
With an lwIP network stack configured for TCP and UDP support (the default configuration), calling accept() with a
datagram socket will cause a failed assertion (if enabled) in the lwIP network stack. If assertion checks are not enabled
in the stack, accept() will fail to indicate an error to the caller when used on a datagram socket.
Issue P00101-13659, inet_addr() does not check the number range in all parts of the address
Function inet_addr() does not check the number range for all parts of the address and fails to return INADDR_NONE
for invalid input data.
Issue P00101-14328, Incorrect result of fabs(-0.0) on 32-bit ARM
When called with -0.0 as argument, function fabs() returns -0.0 instead of 0.0 on 32-bit ARM.
c Copyright 2019 16
All rights reserved.
SYSGO GmbH