On 14/07/2020 06:41, Chris Johns wrote:
On 13/7/20 3:05 pm, Sebastian Huber wrote:
On 13/07/2020 02:09, Chris Johns wrote:
On 8/7/20 9:37 pm, Sebastian Huber wrote:
On 08/07/2020 13:34, Chris Johns wrote:
Are these flags needed for all BSPs?
Yes, these flags are needed to build and use libbsd.
Why not define them for all BSPs
In the new build system they are the default.
and for all applications?
I don't think we should mandate any optimization flags for applications. These
flags affect the code generation.
But there is a class of application, ie linking with libbsd, which must have
these flags as well.
If you link to libbsd, then you need the --gc-sections linker flags. You
don't need the -fdata-sections and -ffunction-sections for the
application code.
What is special about libbsd that it needs these flags over any other type of
application?
libbsd needs these flags since FreeBSD was not designed as a static library. In
addition, the porting to RTEMS is less intrusive and labour intensive using
these flags.
Sure I understand this. Adding the flags to libbsd like this lets libbsd build
it's tests, it however does not transfer through to a user application and this
is what I would like to address. I see libbsd linking a test executable as the
same use case a user has when linking a libbsd application.
Yes, but should we really export some optimization flags through the
RTEMS BSP installation which are only required by libbsd?
If so why add to here ...
https://git.rtems.org/rtems/tree/c/src/bsp.pc.in
These are optimization flags. I thought the consensus was to export only ABI
relevant flags in the new build system.
In CFLAGS yes. Pkgconfig files (.pc) support variables and I had always thought
we define a number of RTEMS specific variables and these hold various flags or
commands needed to handle other things, for example the options to mkimage. A
user could then test for a variable and if present know this BSP does or has
extra "what ever".
You mean some sort of recommended optimization flags? We should really define
what the pkg-config files should export so that I can implement this in the new
build system.
The ABI flags are in CFLAGS. You could define a recommended optimisation set of
flags as a variable. I was thinking of other things like the base addresses or
size limits or even a post link command users can use in a build without needed
to investigate then copy and paste the details.
Maybe pkgconfig can provide more specific support for example we add a .pc for
libbsd and then a user queries it for the needs flags to use?
Since the BSP provides the linker command file I think it is all right
to provide the -Wl,--gc-sections unconditionally via the LDFLAGS of the
pkg-config file. It doesn't affect code generation. It may confuse some
application developers which don't know this linker feature if they see
that some of their data gets magically optimized away and doesn't end up
in the executable.
Providing the -fdata-sections and -ffunction-sections is not necessary.
The application developers should think about this on their own if it
makes sense for the application.
The pkg-config support is one of the last things to clarify in the new
build system.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
