Re: N2X, GR740 and coverage: The impact of a linkcmds patch from 2014 to gcov_init calls
Hi Chris. You can clone this repository: https://github.com/ttsiodras/EmbeddedCoverage ...and then use different build invocations to easily reproduce - like this: First, with an older toolchain: = (master)$ /opt/rtems-4.11/bin/sparc-rtems4.11-gcc -v Using built-in specs. COLLECT_GCC=_sparc-rtems4.11-gcc COLLECT_LTO_WRAPPER=/opt/rtems-4.11/libexec/gcc/sparc-rtems4.11/4.8.1/lto-wrapper Target: sparc-rtems4.11 Configured with: ../gcc-4.8.1/configure --enable-threads -with-gnu-as --with-gnu-ld --with-newlib --verbose --with-system-zlib --disable-nls --enable-version-specific-runtime-libs --enable-languages=c,c++,ada --target=sparc-rtems4.11 --prefix=/opt/rtems-4.11 --with-gmp=/opt/rtems-4.11 --with-mpfr=/opt/rtems-4.11 --with-mpc=/opt/rtems-4.11 Thread model: rtems gcc version 4.8.1 (GCC) (master)$ make PLATFORM=OAR RTEMS=/opt/rtems-4.11 FPU=1 COVERAGE=1 CROSS_PREFIX=sparc-rtems4.11 V=1 CPU=leon3 Generating dependencies for src/gcov_hooks.c Generating dependencies for src/gcc.c Generating dependencies for src/task2.c Generating dependencies for src/task1.c Generating dependencies for src/my_main.c Generating dependencies for src/init.c /opt/rtems-4.11/bin/sparc-rtems4.11-gcc -c -DCOVERAGE_ENABLED -fprofile-arcs -ftest-coverage -Wall -Wextra -g -I src -DOAR -Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs -DDEBUG -O0 -B/opt/rtems-4.11/sparc-rtems4.11/leon3/lib -specs bsp_specs -qrtems -mcpu=cypress -DBSP_leon3 -o objs.debug.leon3.OAR/init.o src/init.c /opt/rtems-4.11/bin/sparc-rtems4.11-gcc -c -DCOVERAGE_ENABLED -fprofile-arcs -ftest-coverage -Wall -Wextra -g -I src -DOAR -Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs -DDEBUG -O0 -B/opt/rtems-4.11/sparc-rtems4.11/leon3/lib -specs bsp_specs -qrtems -mcpu=cypress -DBSP_leon3 -o objs.debug.leon3.OAR/my_main.o src/my_main.c /opt/rtems-4.11/bin/sparc-rtems4.11-gcc -c -DCOVERAGE_ENABLED -fprofile-arcs -ftest-coverage -Wall -Wextra -g -I src -DOAR -Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs -DDEBUG -O0 -B/opt/rtems-4.11/sparc-rtems4.11/leon3/lib -specs bsp_specs -qrtems -mcpu=cypress -DBSP_leon3 -o objs.debug.leon3.OAR/task1.o src/task1.c /opt/rtems-4.11/bin/sparc-rtems4.11-gcc -c -DCOVERAGE_ENABLED -fprofile-arcs -ftest-coverage -Wall -Wextra -g -I src -DOAR -Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs -DDEBUG -O0 -B/opt/rtems-4.11/sparc-rtems4.11/leon3/lib -specs bsp_specs -qrtems -mcpu=cypress -DBSP_leon3 -o objs.debug.leon3.OAR/task2.o src/task2.c /opt/rtems-4.11/bin/sparc-rtems4.11-gcc -c -DCOVERAGE_ENABLED -fprofile-arcs -ftest-coverage -Wall -Wextra -g -I src -DOAR -Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs -DDEBUG -O0 -B/opt/rtems-4.11/sparc-rtems4.11/leon3/lib -specs bsp_specs -qrtems -mcpu=cypress -DBSP_leon3 -o objs.debug.leon3.OAR/gcc.o src/gcc.c /opt/rtems-4.11/bin/sparc-rtems4.11-gcc -c -DCOVERAGE_ENABLED -fprofile-arcs -ftest-coverage -Wall -Wextra -g -I src -DOAR -Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs -DDEBUG -O0 -B/opt/rtems-4.11/sparc-rtems4.11/leon3/lib -specs bsp_specs -qrtems -mcpu=cypress -DBSP_leon3 -o objs.debug.leon3.OAR/gcov_hooks.o src/gcov_hooks.c /opt/rtems-4.11/bin/sparc-rtems4.11-gcc -g -o bin.debug.leon3.OAR/fputest objs.debug.leon3.OAR/init.o objs.debug.leon3.OAR/my_main.o objs.debug.leon3.OAR/task1.o objs.debug.leon3.OAR/task2.o objs.debug.leon3.OAR/gcc.o objs.debug.leon3.OAR/gcov_hooks.o -fprofile-arcs -ftest-coverage -B/opt/rtems-4.11/sparc-rtems4.11/leon3/lib -specs bsp_specs -qrtems -mcpu=cypress Built debug version at bin.debug.leon3.OAR/fputest Build done via RTEMS at /opt/rtems-4.11/sparc-rtems4.11/leon3/lib for leon3. = With the old toolchain, CTOR_LIST contains this: = (master)$ sparc-rtems4.11-objdump -d -x -S ./bin.debug.leon3.OAR/fputest | grep -A6 '<__CTOR_LIST__>' 4001d100 <__CTOR_LIST__>: 4001d100: ff ff ff ff 40 00 13 ac 40 00 14 54 40 00 18 54 @...@..T@..T 4001d110: 40 00 1b 38 40 00 22 4c 40 00 25 c0 @..8@."L@.%. 4001d11c <__CTOR_END__>: 4001d11c: 00 00 00 00 = ...so the addresses of the "coverage stubs" are indeed stored in __CTOR_LIST__. Then, with rtems 4.12: = (master)$ make clean (master)$ make PLATFORM=OAR RTEMS=/opt/rtems-4.12 FPU=1 COVERAGE=1 CROSS_PREFIX=sparc-rtems4.12 V=1 CPU=leon3 Generating dependencies for src/gcov_hooks.c Generating dependencies for src/gcc.c Generating dependencies for src/task2.c Generating dependencies for src/task1.c Generating dependencies for src/my_main.c Generating dependencies for src/init.c /opt/rtems-4.12/bin/sparc
Re: POSIX and return codes...
- Am 27. Feb 2018 um 13:11 schrieb Jakob Viketoft jakob.viket...@aacmicrotec.com: > From: Joel Sherrill [j...@rtems.org] > Sent: Monday, February 26, 2018 14:36 >>> On Feb 26, 2018 8:27 AM, "Jakob Viketoft" >>> wrote: > >>> Hello Joel, > >>> From: Joel Sherrill [j...@rtems.org] >>> Sent: Monday, February 26, 2018 12:21 > On Feb 26, 2018 5:13 AM, "Jakob Viketoft" wrote: > E.g. could it be possible for the translation mechanism to look if there > is > already an errno defined and then return this instead of doing the error > code > translation? > > It seems like the translation I'm talking about happens in the > rtems_deviceio_write() function in > cpukit/libcsupport/src/sup_fs_deviceio.c > Completely random thought as I sit on a plane without code. > Add a field to the arguments structure for errno. See it to zero before the call. If it is set to non-zero after the call, then the driver wanted to return errno directly. Otherwise translate. > >>> This was my thought as well, I just wanted to bounce it off the RTEMS list >>> and >>> also possibly get official support for a feature as this. > >> Now boarded on a different plane and have had another round of thinking. > >> What if an RTEMS status code were added like RTEMS_STATUS_IN_ERRNO and we >> don't >> modify the arguments structure. Then a driver could return that status to >> trip >> -1 and errno. > > Yes, that would work just as well for us and is even less work / impact. > >> Just a thought. I think it would make the code cleaner but another core >> developer should pipe up. I was up at 3am to catch a flight and could be >> loopy. >> :) > > Anyone else? :) I think you try to improve the wrong driver framework. This classic device support is a legacy API. It is inflexible and has a considerable overhead due to an excessive layering and the use of minor numbers. A driver registered via IMFS_make_generic_node() already provides the functionality you are asking. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: N2X, GR740 and coverage: The impact of a linkcmds patch from 2014 to gcov_init calls
- Am 27. Feb 2018 um 17:30 schrieb Thanassis Tsiodras
thanassis.tsiod...@esa.int:
[...]
> After quite a lot of hunting, we traced this failure to a patch in the
> "linkcmds.base" - done back in 2014 ( commit 95cb09ed746 ) :
>
> This commit changed "c/src/lib/libbsp/sparc/shared/startup/linkcmds.base"
> from this:
>
>KEEP (*(SORT(.ctors.*)))
>KEEP (*(.ctors))
>KEEP (*crtbegin.o(.dtors))
>KEEP (*crtbegin?.o(.dtors))
>KEEP (*(EXCLUDE_FILE (*crtend.o *crtend?.o ) .dtors))
>KEEP (*(SORT(.dtors.*)))
>KEEP (*(.dtors))
>
> ...to this:
>
>KEEP (*(EXCLUDE_FILE (*crtend.o *crtend?.o ) .ctors))
>KEEP (*(SORT(.ctors*)))
>KEEP (*crtbegin.o(.dtors))
>KEEP (*crtbegin?.o(.dtors))
>KEEP (*(EXCLUDE_FILE (*crtend.o *crtend?.o ) .dtors))
>KEEP (*(SORT(.dtors*)))
>
> Reverting this change, the gcov stubs revert back to their proper place,
> and __gcov_inits are called properly.
>
> The reason I tried this patch, was because I noticed that the coverage
> stubs are no longer placed in ".ctor" sections - they are instead placed
> by the newer compilers at ".ctor.NUMBER" sections (with NUMBER set to
> 65435 in my case - but I am guessing this will change from invocation to
> invocation).
>
> The comment provided by Joel back in 2014, only indicated that this patch
> was done to address C++ concerns:
>
> commit 95cb09ed746e7daeca2158c7ecdf0249cfcbc5c8
> Author: Joel Sherrill
> Date: Wed Apr 2 11:39:20 2014 -0500
>
>sparc/shared/.../linkcmds.base: Correct C++ support
>Add KEEP() for .eh_frame*, .ctor*, and .dtor*.
It could be a bug in the linker. The standard sections should be exactly like
the Binutils default:
sparc-rtems5-ld --verbose | grep ctor -C 3
*(.rela.data .rela.data.* .rela.gnu.linkonce.d.*)
*(.rela.tdata .rela.tdata.* .rela.gnu.linkonce.td.*)
*(.rela.tbss .rela.tbss.* .rela.gnu.linkonce.tb.*)
*(.rela.ctors)
*(.rela.dtors)
*(.rela.got)
*(.rela.bss .rela.bss.* .rela.gnu.linkonce.b.*)
--
.init_array :
{
PROVIDE_HIDDEN (__init_array_start = .);
KEEP (*(SORT_BY_INIT_PRIORITY(.init_array.*)
SORT_BY_INIT_PRIORITY(.ctors.*)))
KEEP (*(.init_array EXCLUDE_FILE (*crtbegin.o *crtbegin?.o *crtend.o
*crtend?.o ) .ctors))
PROVIDE_HIDDEN (__init_array_end = .);
}
.fini_array :
--
KEEP (*(.fini_array EXCLUDE_FILE (*crtbegin.o *crtbegin?.o *crtend.o
*crtend?.o ) .dtors))
PROVIDE_HIDDEN (__fini_array_end = .);
}
.ctors :
{
/* gcc uses crtbegin.o to find the start of
the constructors, so we make sure it is
first. Because this is a wildcard, it
doesn't matter if the user does not
actually link against crtbegin.o; the
linker won't look for a file to match a
wildcard. The wildcard also means that it
doesn't matter which directory crtbegin.o
is in. */
KEEP (*crtbegin.o(.ctors))
KEEP (*crtbegin?.o(.ctors))
/* We don't want to include the .ctor section from
the crtend.o file until after the sorted ctors.
The .ctor section from the crtend file contains the
end of ctors marker and it must be last */
KEEP (*(EXCLUDE_FILE (*crtend.o *crtend?.o ) .ctors))
KEEP (*(SORT(.ctors.*)))
KEEP (*(.ctors))
}
.dtors :
{
However, I am not able to reproduce this problem. For example in the sptls04
linker map file (-Wl,-Map,map.txt) we have this:
*crtbegin.o(.ctors)
.ctors 0x020113300x4
/opt/rtems/5/lib/gcc/sparc-rtems5/7.3.0/crtbegin.o
*crtbegin?.o(.ctors)
*(EXCLUDE_FILE(*crtend?.o *crtend.o) .ctors)
.ctors 0x020113340x4 init.o
*(SORT_BY_NAME(.ctors*))
.ctors 0x020113380x4
/opt/rtems/5/lib/gcc/sparc-rtems5/7.3.0/crtend.o
Who do the linker map files look in your test case?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: N2X, GR740 and coverage: The impact of a linkcmds patch from 2014 to gcov_init calls
> However, I am not able to reproduce this problem.
Hi Sebastian.
Look at the reply I sent this morning to the mailing list - I uploaded the
code in a GitHub repository and provided instructions in the mailing list
with the exact invocations that reproduce the issue.
Hope this helps!
Thanassis.
Thanassis Tsiodras
Real-time Embedded Software Engineer
System, Software and Technology Department
ESTEC
Keplerlaan 1, PO Box 299
NL-2200 AG Noordwijk, The Netherlands
thanassis.tsiod...@esa.int | www.esa.int
T +31 71 565 5332
From: Sebastian Huber
To: Thanassis Tsiodras
Cc: devel
Date: 28/02/2018 12:11
Subject:Re: N2X, GR740 and coverage: The impact of a linkcmds
patch from 2014 to gcov_init calls
- Am 27. Feb 2018 um 17:30 schrieb Thanassis Tsiodras
thanassis.tsiod...@esa.int:
[...]
> After quite a lot of hunting, we traced this failure to a patch in the
> "linkcmds.base" - done back in 2014 ( commit 95cb09ed746 ) :
>
> This commit changed
"c/src/lib/libbsp/sparc/shared/startup/linkcmds.base"
> from this:
>
>KEEP (*(SORT(.ctors.*)))
>KEEP (*(.ctors))
>KEEP (*crtbegin.o(.dtors))
>KEEP (*crtbegin?.o(.dtors))
>KEEP (*(EXCLUDE_FILE (*crtend.o *crtend?.o ) .dtors))
>KEEP (*(SORT(.dtors.*)))
>KEEP (*(.dtors))
>
> ...to this:
>
>KEEP (*(EXCLUDE_FILE (*crtend.o *crtend?.o ) .ctors))
>KEEP (*(SORT(.ctors*)))
>KEEP (*crtbegin.o(.dtors))
>KEEP (*crtbegin?.o(.dtors))
>KEEP (*(EXCLUDE_FILE (*crtend.o *crtend?.o ) .dtors))
>KEEP (*(SORT(.dtors*)))
>
> Reverting this change, the gcov stubs revert back to their proper place,
> and __gcov_inits are called properly.
>
> The reason I tried this patch, was because I noticed that the coverage
> stubs are no longer placed in ".ctor" sections - they are instead placed
> by the newer compilers at ".ctor.NUMBER" sections (with NUMBER set to
> 65435 in my case - but I am guessing this will change from invocation to
> invocation).
>
> The comment provided by Joel back in 2014, only indicated that this
patch
> was done to address C++ concerns:
>
> commit 95cb09ed746e7daeca2158c7ecdf0249cfcbc5c8
> Author: Joel Sherrill
> Date: Wed Apr 2 11:39:20 2014 -0500
>
>sparc/shared/.../linkcmds.base: Correct C++ support
>Add KEEP() for .eh_frame*, .ctor*, and .dtor*.
It could be a bug in the linker. The standard sections should be exactly
like the Binutils default:
sparc-rtems5-ld --verbose | grep ctor -C 3
*(.rela.data .rela.data.* .rela.gnu.linkonce.d.*)
*(.rela.tdata .rela.tdata.* .rela.gnu.linkonce.td.*)
*(.rela.tbss .rela.tbss.* .rela.gnu.linkonce.tb.*)
*(.rela.ctors)
*(.rela.dtors)
*(.rela.got)
*(.rela.bss .rela.bss.* .rela.gnu.linkonce.b.*)
--
.init_array :
{
PROVIDE_HIDDEN (__init_array_start = .);
KEEP (*(SORT_BY_INIT_PRIORITY(.init_array.*)
SORT_BY_INIT_PRIORITY(.ctors.*)))
KEEP (*(.init_array EXCLUDE_FILE (*crtbegin.o *crtbegin?.o *crtend.o
*crtend?.o ) .ctors))
PROVIDE_HIDDEN (__init_array_end = .);
}
.fini_array :
--
KEEP (*(.fini_array EXCLUDE_FILE (*crtbegin.o *crtbegin?.o *crtend.o
*crtend?.o ) .dtors))
PROVIDE_HIDDEN (__fini_array_end = .);
}
.ctors :
{
/* gcc uses crtbegin.o to find the start of
the constructors, so we make sure it is
first. Because this is a wildcard, it
doesn't matter if the user does not
actually link against crtbegin.o; the
linker won't look for a file to match a
wildcard. The wildcard also means that it
doesn't matter which directory crtbegin.o
is in. */
KEEP (*crtbegin.o(.ctors))
KEEP (*crtbegin?.o(.ctors))
/* We don't want to include the .ctor section from
the crtend.o file until after the sorted ctors.
The .ctor section from the crtend file contains the
end of ctors marker and it must be last */
KEEP (*(EXCLUDE_FILE (*crtend.o *crtend?.o ) .ctors))
KEEP (*(SORT(.ctors.*)))
KEEP (*(.ctors))
}
.dtors :
{
However, I am not able to reproduce this problem. For example in the
sptls04 linker map file (-Wl,-Map,map.txt) we have this:
*crtbegin.o(.ctors)
.ctors 0x020113300x4
/opt/rtems/5/lib/gcc/sparc-rtems5/7.3.0/crtbegin.o
*crtbegin?.o(.ctors)
*(EXCLUDE_FILE(*crtend?.o *crtend.o) .ctors)
.ctors 0x020113340x4 init.o
*(SORT_BY_NAME(.ctors*))
.ctors 0x020113380x4
/opt/rtems/5/lib/gcc/sparc-rtems5/7.3.0/crtend.o
Who do the linker map files look in your test case?
This message and any attachments are intended for the use of the addressee or
addressees only.
The unauthorised disclosure, use, dissemination or copying (either in whole or
in part) of its
content is not permitted.
If you received this message in error, please notify the sender and delete it
from your system.
Emails can be altered and their integrity cannot be guaranteed by the sende
Re: N2X, GR740 and coverage: The impact of a linkcmds patch from 2014 to gcov_init calls
It was a bug in the linker command file. See attached patches.
- Am 28. Feb 2018 um 12:50 schrieb Thanassis Tsiodras
thanassis.tsiod...@esa.int:
>> However, I am not able to reproduce this problem.
>
> Hi Sebastian.
>
> Look at the reply I sent this morning to the mailing list - I uploaded the
> code in a GitHub repository and provided instructions in the mailing list
> with the exact invocations that reproduce the issue.
>
> Hope this helps!
> Thanassis.
>
> Thanassis Tsiodras
> Real-time Embedded Software Engineer
> System, Software and Technology Department
>
> ESTEC
> Keplerlaan 1, PO Box 299
> NL-2200 AG Noordwijk, The Netherlands
> thanassis.tsiod...@esa.int | www.esa.int
> T +31 71 565 5332
>
>
>
> From: Sebastian Huber
> To: Thanassis Tsiodras
> Cc: devel
> Date: 28/02/2018 12:11
> Subject:Re: N2X, GR740 and coverage: The impact of a linkcmds
> patch from 2014 to gcov_init calls
>
>
>
> - Am 27. Feb 2018 um 17:30 schrieb Thanassis Tsiodras
> thanassis.tsiod...@esa.int:
>
> [...]
>> After quite a lot of hunting, we traced this failure to a patch in the
>> "linkcmds.base" - done back in 2014 ( commit 95cb09ed746 ) :
>>
>> This commit changed
> "c/src/lib/libbsp/sparc/shared/startup/linkcmds.base"
>> from this:
>>
>>KEEP (*(SORT(.ctors.*)))
>>KEEP (*(.ctors))
>>KEEP (*crtbegin.o(.dtors))
>>KEEP (*crtbegin?.o(.dtors))
>>KEEP (*(EXCLUDE_FILE (*crtend.o *crtend?.o ) .dtors))
>>KEEP (*(SORT(.dtors.*)))
>>KEEP (*(.dtors))
>>
>> ...to this:
>>
>>KEEP (*(EXCLUDE_FILE (*crtend.o *crtend?.o ) .ctors))
>>KEEP (*(SORT(.ctors*)))
>>KEEP (*crtbegin.o(.dtors))
>>KEEP (*crtbegin?.o(.dtors))
>>KEEP (*(EXCLUDE_FILE (*crtend.o *crtend?.o ) .dtors))
>>KEEP (*(SORT(.dtors*)))
>>
>> Reverting this change, the gcov stubs revert back to their proper place,
>> and __gcov_inits are called properly.
>>
>> The reason I tried this patch, was because I noticed that the coverage
>> stubs are no longer placed in ".ctor" sections - they are instead placed
>> by the newer compilers at ".ctor.NUMBER" sections (with NUMBER set to
>> 65435 in my case - but I am guessing this will change from invocation to
>> invocation).
>>
>> The comment provided by Joel back in 2014, only indicated that this
> patch
>> was done to address C++ concerns:
>>
>> commit 95cb09ed746e7daeca2158c7ecdf0249cfcbc5c8
>> Author: Joel Sherrill
>> Date: Wed Apr 2 11:39:20 2014 -0500
>>
>>sparc/shared/.../linkcmds.base: Correct C++ support
>>Add KEEP() for .eh_frame*, .ctor*, and .dtor*.
>
> It could be a bug in the linker. The standard sections should be exactly
> like the Binutils default:
>
> sparc-rtems5-ld --verbose | grep ctor -C 3
> *(.rela.data .rela.data.* .rela.gnu.linkonce.d.*)
> *(.rela.tdata .rela.tdata.* .rela.gnu.linkonce.td.*)
> *(.rela.tbss .rela.tbss.* .rela.gnu.linkonce.tb.*)
> *(.rela.ctors)
> *(.rela.dtors)
> *(.rela.got)
> *(.rela.bss .rela.bss.* .rela.gnu.linkonce.b.*)
> --
> .init_array :
> {
>PROVIDE_HIDDEN (__init_array_start = .);
>KEEP (*(SORT_BY_INIT_PRIORITY(.init_array.*)
> SORT_BY_INIT_PRIORITY(.ctors.*)))
>KEEP (*(.init_array EXCLUDE_FILE (*crtbegin.o *crtbegin?.o *crtend.o
> *crtend?.o ) .ctors))
>PROVIDE_HIDDEN (__init_array_end = .);
> }
> .fini_array :
> --
>KEEP (*(.fini_array EXCLUDE_FILE (*crtbegin.o *crtbegin?.o *crtend.o
> *crtend?.o ) .dtors))
>PROVIDE_HIDDEN (__fini_array_end = .);
> }
> .ctors :
> {
>/* gcc uses crtbegin.o to find the start of
> the constructors, so we make sure it is
> first. Because this is a wildcard, it
> doesn't matter if the user does not
> actually link against crtbegin.o; the
> linker won't look for a file to match a
> wildcard. The wildcard also means that it
> doesn't matter which directory crtbegin.o
> is in. */
>KEEP (*crtbegin.o(.ctors))
>KEEP (*crtbegin?.o(.ctors))
>/* We don't want to include the .ctor section from
> the crtend.o file until after the sorted ctors.
> The .ctor section from the crtend file contains the
> end of ctors marker and it must be last */
>KEEP (*(EXCLUDE_FILE (*crtend.o *crtend?.o ) .ctors))
>KEEP (*(SORT(.ctors.*)))
>KEEP (*(.ctors))
> }
> .dtors :
> {
>
> However, I am not able to reproduce this problem. For example in the
> sptls04 linker map file (-Wl,-Map,map.txt) we have this:
>
> *crtbegin.o(.ctors)
> .ctors 0x020113300x4
> /opt/rtems/5/lib/gcc/sparc-rtems5/7.3.0/crtbegin.o
> *crtbegin?.o(.ctors)
> *(EXCLUDE_FILE(*crtend?.o *crtend.o) .ctors)
> .ctors 0x020113340x4 init.o
> *(SORT_BY_NAME(.ctors*))
> .ctors 0x020113380x4
> /opt/rtems/5/lib/gcc/sparc-rtems5/7.3.0/crtend.o
>
> Who do the linker map files look in your test case?
>
>
>
> This message and any attachments are intended
RE: POSIX and return codes...
Hello Sebastian, From: Sebastian Huber [sebastian.hu...@embedded-brains.de] Sent: Wednesday, February 28, 2018 11:55 > - Am 27. Feb 2018 um 13:11 schrieb Jakob Viketoft > jakob.viket...@aacmicrotec.com: > >> From: Joel Sherrill [j...@rtems.org] >> Sent: Monday, February 26, 2018 14:36 On Feb 26, 2018 8:27 AM, "Jakob Viketoft" wrote: >> Hello Joel, >> From: Joel Sherrill [j...@rtems.org] Sent: Monday, February 26, 2018 12:21 >> > On Feb 26, 2018 5:13 AM, "Jakob Viketoft" > wrote: >> E.g. could it be possible for the translation mechanism to look if there >> is >> already an errno defined and then return this instead of doing the error >> code >> translation? >> >> It seems like the translation I'm talking about happens in the >> rtems_deviceio_write() function in >> cpukit/libcsupport/src/sup_fs_deviceio.c >> > Completely random thought as I sit on a plane without code. >> > Add a field to the arguments structure for errno. See it to zero before > the > call. If it is set to non-zero after the call, then the driver wanted to > return > errno directly. Otherwise translate. >> This was my thought as well, I just wanted to bounce it off the RTEMS list and also possibly get official support for a feature as this. >> >>> Now boarded on a different plane and have had another round of thinking. >> >>> What if an RTEMS status code were added like RTEMS_STATUS_IN_ERRNO and we >>> don't >>> modify the arguments structure. Then a driver could return that status to >>> trip >>> -1 and errno. >> >> Yes, that would work just as well for us and is even less work / impact. >> >>> Just a thought. I think it would make the code cleaner but another core >>> developer should pipe up. I was up at 3am to catch a flight and could be >>> loopy. >>> :) >> >> Anyone else? :) > > I think you try to improve the wrong driver framework. This classic device > support is a legacy API. It is inflexible > and has a considerable overhead due to an excessive layering and the use of > minor numbers. A driver registered > via IMFS_make_generic_node() already provides the functionality you are > asking. I agree with the excessive layering, but it's not straightforward how IMFS_make_generic_node() works. Looking at e.g. https://git.rtems.org/rtems/tree/testsuites/libtests/newlib01/init.c, it seems like driver *user* is calling IMFS_make_generic_node() which seems a bit absurd (correct me if I'm wrong). You also noted that the API isn't stable yet which make me hesitate about switching over to this. Practically speaking, I think need we have to have an immediate interim solution, along the lines Joel suggested, and then long term we could switch over to the IMFS_make_generic_node() way of doing things. However, I would need some more documentation on IMFS_make_generic_node() besides looking at examples in testsuites code. The current POSIX API is what's exposed to our users and changing that in any way is not done at the flip of a coin. We don't have any other filesystems in RTEMS (apart from /dev/*) if that has any impact either way. /Jakob ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
