GNU ld --wrap limitations
Hello,
while testing the event recording with the libbsd I noticed a GNU ld
--wrap limitation:
https://www.sourceware.org/ml/binutils/2018-12/msg00210.html
It turned out that the wrapping doesn't work for references internal to
a translation unit. My hope was that the RTEMS Trace Linker doesn't have
this limitation, but the documentation says (user manual):
"The trace linker’s major role is to wrap functions in the existing
executable with trace code. The
directions on how to wrap application functions is provided by the
generator configuration. The
wrapping function uses a GNU linker option called –wrap=symbol."
In the libbsd a lot of things are done through function pointer
assignments, e.g.
static struct netisr_handler ip_nh = {
.nh_name = "ip",
.nh_handler = ip_input,
.nh_proto = NETISR_IP,
#ifdef RSS
.nh_m2cpuid = rss_soft_m2cpuid_v4,
.nh_policy = NETISR_POLICY_CPU,
.nh_dispatch = NETISR_DISPATCH_HYBRID,
#else
.nh_policy = NETISR_POLICY_FLOW,
#endif
};
or
/*
* Perform common duties while attaching to interface list
*/
void
ether_ifattach(struct ifnet *ifp, const u_int8_t *lla)
{
int i;
struct ifaddr *ifa;
struct sockaddr_dl *sdl;
ifp->if_addrlen = ETHER_ADDR_LEN;
ifp->if_hdrlen = ETHER_HDR_LEN;
if_attach(ifp);
ifp->if_mtu = ETHERMTU;
ifp->if_output = ether_output;
ifp->if_input = ether_input;
This makes the tracing quite ineffective in this area.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
RTEMS Open Class in Huntsville AL US Feb 25-March 1
Hi There will be an RTEMS Open Class in Huntsville Alabama the week of February 25 - March 1. February 25- Getting Started February 26 - March 1 - Open Class Details and registration forms at http://rtems.com/trainingschedule. If you have questions at all about the class, feel free to email me directly. I am looking forward to the first class in our new offices. :) Thanks. --joel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GNU ld --wrap limitations
On 14/1/19 8:22 pm, Sebastian Huber wrote:
>
> while testing the event recording with the libbsd I noticed a GNU ld --wrap
> limitation:
>
> https://www.sourceware.org/ml/binutils/2018-12/msg00210.html
>
I have been watching the thread. There is a limit to what binutils or any method
can do as compiler technology improves.
An example we currently build RTEMS with a single C file on the command line, I
wonder what RTEMS's score would look like if all C files are passed to the
compiler at once and it can optimise over all files as if included in a single
source file. A number of externals we current have would not be visible and
traceable using this method.
> It turned out that the wrapping doesn't work for references internal to a
> translation unit.
The reach for this issue is changing as the push to better optimise the
generated code. If the compiler can remove or optimise an external call as an
internally reference it will.
> My hope was that the RTEMS Trace Linker doesn't have this
> limitation, but the documentation says (user manual):
>
> "The trace linker’s major role is to wrap functions in the existing executable
> with trace code. The
> directions on how to wrap application functions is provided by the generator
> configuration. The
> wrapping function uses a GNU linker option called –wrap=symbol."
>
https://devel.rtems.org/wiki/Developer/Tracing/Trace_Linker#Limitation
... highlights the need for an external reference.
> In the libbsd a lot of things are done through function pointer assignments,
> e.g.
>
> static struct netisr_handler ip_nh = {
> .nh_name = "ip",
> .nh_handler = ip_input,
> .nh_proto = NETISR_IP,
> #ifdef RSS
> .nh_m2cpuid = rss_soft_m2cpuid_v4,
> .nh_policy = NETISR_POLICY_CPU,
> .nh_dispatch = NETISR_DISPATCH_HYBRID,
> #else
> .nh_policy = NETISR_POLICY_FLOW,
> #endif
> };
>
> or
>
> /*
> * Perform common duties while attaching to interface list
> */
> void
> ether_ifattach(struct ifnet *ifp, const u_int8_t *lla)
> {
> int i;
> struct ifaddr *ifa;
> struct sockaddr_dl *sdl;
>
> ifp->if_addrlen = ETHER_ADDR_LEN;
> ifp->if_hdrlen = ETHER_HDR_LEN;
> if_attach(ifp);
> ifp->if_mtu = ETHERMTU;
> ifp->if_output = ether_output;
> ifp->if_input = ether_input;
>
> This makes the tracing quite ineffective in this area.
>
I suspect the compiler is using a local offset to the code in the file. There
are other cases, for example C++.
I have recently been considering the role libdl can place in hooking trace code
and the effect of deferring the ability to wrap to the target. I suspect it
would not resolve the problem you face because there are no reloc records to the
internal offsets being used but I have not checked. If the DWARF info holds call
or block data maybe hot patching the code might be possible. This would need
host processing to extract the hot patch data.
I consider the wrap method of tracing as a low cost portable API tracer that is
useful for things like malloc/free. It is not like a hardware trace device that
can see everything so I consider there exists a cost/functionality curve.
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: GNU ld --wrap limitations
On 14/01/2019 23:33, Chris Johns wrote:
On 14/1/19 8:22 pm, Sebastian Huber wrote:
while testing the event recording with the libbsd I noticed a GNU ld --wrap
limitation:
https://www.sourceware.org/ml/binutils/2018-12/msg00210.html
I have been watching the thread. There is a limit to what binutils or any method
can do as compiler technology improves.
An example we currently build RTEMS with a single C file on the command line, I
wonder what RTEMS's score would look like if all C files are passed to the
compiler at once and it can optimise over all files as if included in a single
source file. A number of externals we current have would not be visible and
traceable using this method.
If I use -flto in my simple test case, then the wrapping via LD doesn't
work at all.
It turned out that the wrapping doesn't work for references internal to a
translation unit.
The reach for this issue is changing as the push to better optimise the
generated code. If the compiler can remove or optimise an external call as an
internally reference it will.
This is not a compiler optimization issue. The wrapping doesn't work
with -O0 for all references internal to the translation unit. For example:
cat f.c
#include "f.h"
#include
void h(void)
{
puts(__PRETTY_FUNCTION__);
}
func f(void)
{
h();
puts(__PRETTY_FUNCTION__);
return g;
}
cat f.s
.file "f.c"
.text
.globl h
.type h, @function
h:
.LFB0:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq %rsp, %rbp
.cfi_def_cfa_register 6
movl $__PRETTY_FUNCTION__.2272, %edi
call puts
nop
popq %rbp
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE0:
.size h, .-h
.globl f
.type f, @function
f:
.LFB1:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq %rsp, %rbp
.cfi_def_cfa_register 6
call h
movl $__PRETTY_FUNCTION__.2276, %edi
call puts
movl $g, %eax
popq %rbp
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE1:
.size f, .-f
.section .rodata
.type __PRETTY_FUNCTION__.2272, @object
.size __PRETTY_FUNCTION__.2272, 2
__PRETTY_FUNCTION__.2272:
.string "h"
.type __PRETTY_FUNCTION__.2276, @object
.size __PRETTY_FUNCTION__.2276, 2
__PRETTY_FUNCTION__.2276:
.string "f"
.ident "GCC: (SUSE Linux) 7.4.0"
.section .note.GNU-stack,"",@progbits
You see "call h" and "call puts". The h() function is defined in the
translation unit. This call is not wrapped.
My hope was that the RTEMS Trace Linker doesn't have this
limitation, but the documentation says (user manual):
"The trace linker’s major role is to wrap functions in the existing executable
with trace code. The
directions on how to wrap application functions is provided by the generator
configuration. The
wrapping function uses a GNU linker option called –wrap=symbol."
https://devel.rtems.org/wiki/Developer/Tracing/Trace_Linker#Limitation
... highlights the need for an external reference.
It says
"Functions must have external linkage to allow the linker to wrap the
symbol."
this is not the same as
"highlights the need for an external reference"
You need an undefined reference to a symbol. References inside a
translation unit are apparently not undefined references.
In the libbsd a lot of things are done through function pointer assignments,
e.g.
static struct netisr_handler ip_nh = {
.nh_name = "ip",
.nh_handler = ip_input,
.nh_proto = NETISR_IP,
#ifdef RSS
.nh_m2cpuid = rss_soft_m2cpuid_v4,
.nh_policy = NETISR_POLICY_CPU,
.nh_dispatch = NETISR_DISPATCH_HYBRID,
#else
.nh_policy = NETISR_POLICY_FLOW,
#endif
};
or
/*
* Perform common duties while attaching to interface list
*/
void
ether_ifattach(struct ifnet *ifp, const u_int8_t *lla)
{
int i;
struct ifaddr *ifa;
struct sockaddr_dl *sdl;
ifp->if_addrlen = ETHER_ADDR_LEN;
ifp->if_hdrlen = ETHER_HDR_LEN;
if_attach(ifp);
ifp->if_mtu = ETHERMTU;
ifp->if_output = ether_output;
ifp->if_input = ether_input;
This makes the tracing quite ineffective in this area.
I suspect the compiler is using a local offset to the code in the file. There
are other cases, for example C++.
I have recently been considering the role libdl can place in hooking trace code
and the effect of deferring the ability to wrap to the target. I suspect it
would not resolve the problem you face because there are no reloc records to the
internal offsets being used but I have not checked. If the DWARF info holds call
or block data maybe hot patching the code might be possible. This would need
host processing to extract the hot patch d
Re: Zynq RTEMS 5 SMP Crashing on call to connect in socket.h [Solved]
Hello Avi,
On 13/01/2019 22:51, Misra, Avinash wrote:
Hi,
My issue turned out to be a configuration issue where I was using the
incorrect scheduler. I was originally using #define
CONFIGURE_SCHEDULER_PRIORITY_AFFINITY_SMP when in fact I should have
been using #define CONFIGURE_SCHEDULER_EDF_SMP. This thread
(https://lists.rtems.org/pipermail/devel/2018-October/023349.html)
made that very clear to me.
why did you use a custom scheduler configuration?
However, I do wonder if this is documented as part of the BSD
documentation and I missed it? Is this already well documented or is
this something that should be included with the BSD/RTEMS Networking
documentation?
I think this should be documented in
https://git.rtems.org/rtems-libbsd/tree/libbsd.txt
This file needs an update in general.
Thanks,
Avi
*From:* devel *On Behalf Of *Misra, Avinash
*Sent:* Sunday, January 13, 2019 1:04 PM
*To:* rtems-de...@rtems.org
*Subject:* Zynq RTEMS 5 SMP Crashing on call to connect in socket.h
Hi,
I’m having a peculiar issue when running RTEMS in a SMP configuration
and trying to call connect on a TCP Client Socket which is that RTEMS
crashes when calling the system connect routine with the following error:
Fatal source: 10
Fatal Code: 7 <0x0007>
RTEMS version: 5.0.0.b3c624d8886db6e791babe5e0d4f8b28992e000a
RTEMS tools: 7.3.0 20180125 (RTEMS 5, RSB
9955b1a430677b12c04c77eb6502fae4bb6947b2, Newlib
08eab6396f678cf5e5968acaed0bae9fd129983b)
Executing Thread ID: 0x08a010003
Executing Thread Name: IRQS
This only seems to occur when I configure RTEMS to execute on both
cores of the A9 processor (by setting #define
CONFIGURE_MAXIMUM_PROCESSORS to 2). When I have #define
CONFIGURE_MAXIMUM_PROCESSORS set to 1 the program runs as expected,
connects to my TCP server and sends nominal data. Also, for what it’s
worth, the name of my task is not IRQS so I’m not sure why I keep
getting this exception in the IRQS thread.
My system.hdf file and MMU setup code look as follow:
System.hdf:
MMU Configuration file:
*#include*
*#include*
*#include*
*#include*
*#include*
BSP_START_DATA_SECTION*static**const*arm_cp15_start_section_config
zynq_mmu_config_table[] = {
ARMV7_CP15_START_DEFAULT_SECTIONS,
{
.begin = 0xE000U,
.end = 0xE030U,
.flags = ARMV7_MMU_DEVICE | ARM_MMU_SECT_S
},{
.begin = 0xF800U,
.end = 0xF900U,
.flags = ARMV7_MMU_DEVICE | ARM_MMU_SECT_S
},{
.begin = 0xU, /*RAM 0 START ADDR*/
.end = 0x0002U, /*RAM 0 END ADDR*/
.flags = ARMV7_MMU_DEVICE | ARM_MMU_SECT_S
},{
.begin = 0xU, /*RAM 1 START ADDR*/
.end = 0xFDFFU, /*RAM 1 END ADDR*/
.flags = ARMV7_MMU_DEVICE | ARM_MMU_SECT_S
},{
.begin = 0x4120U, /*AXI GPIO*/
.end = 0x4120U, /*AXI GPIO*/
.flags = ARMV7_MMU_DEVICE | ARM_MMU_SECT_S
}
};
BSP_START_TEXT_SECTION *void**zynq_setup_mmu_and_cache*(*void*)
{
uint32_tctrl = arm_cp15_start_setup_mmu_and_cache(
ARM_CP15_CTRL_A,
ARM_CP15_CTRL_AFE | ARM_CP15_CTRL_Z
);
arm_cp15_start_setup_translation_table_and_enable_mmu_and_cache(
ctrl,
(uint32_t*) bsp_translation_table_base,
ARM_MMU_DEFAULT_CLIENT_DOMAIN,
&zynq_mmu_config_table[0],
RTEMS_ARRAY_SIZE(zynq_mmu_config_table)
);
}
Does anyone have an idea of as to what may be going on here?
Thanks,
Avi
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
RE: Zynq RTEMS 5 SMP Crashing on call to connect in socket.h [Solved]
Hi Sebastian,
Thank you for your response. I was using a custom scheduler configuration
because of one of the RTEM smp examples I saw. I didn't realize that it would
end up affecting BSD and the networking protocol.
I've switched back to the EDF scheduler since and have been having much success
with BSD and the networking stack.
Thanks,
Avi
-Original Message-
From: Sebastian Huber
Sent: Tuesday, January 15, 2019 2:20 AM
To: Misra, Avinash ; rtems-de...@rtems.org
Subject: Re: Zynq RTEMS 5 SMP Crashing on call to connect in socket.h [Solved]
Hello Avi,
On 13/01/2019 22:51, Misra, Avinash wrote:
>
> Hi,
>
> My issue turned out to be a configuration issue where I was using the
> incorrect scheduler. I was originally using #define
> CONFIGURE_SCHEDULER_PRIORITY_AFFINITY_SMP when in fact I should have
> been using #define CONFIGURE_SCHEDULER_EDF_SMP. This thread
> (https://lists.rtems.org/pipermail/devel/2018-October/023349.html)
> made that very clear to me.
>
why did you use a custom scheduler configuration?
> However, I do wonder if this is documented as part of the BSD
> documentation and I missed it? Is this already well documented or is
> this something that should be included with the BSD/RTEMS Networking
> documentation?
>
I think this should be documented in
https://git.rtems.org/rtems-libbsd/tree/libbsd.txt
This file needs an update in general.
> Thanks,
>
> Avi
>
> *From:* devel *On Behalf Of *Misra, Avinash
> *Sent:* Sunday, January 13, 2019 1:04 PM
> *To:* rtems-de...@rtems.org
> *Subject:* Zynq RTEMS 5 SMP Crashing on call to connect in socket.h
>
> Hi,
>
> I'm having a peculiar issue when running RTEMS in a SMP configuration
> and trying to call connect on a TCP Client Socket which is that RTEMS
> crashes when calling the system connect routine with the following error:
>
> Fatal source: 10
>
> Fatal Code: 7 <0x0007>
>
> RTEMS version: 5.0.0.b3c624d8886db6e791babe5e0d4f8b28992e000a
>
> RTEMS tools: 7.3.0 20180125 (RTEMS 5, RSB
> 9955b1a430677b12c04c77eb6502fae4bb6947b2, Newlib
> 08eab6396f678cf5e5968acaed0bae9fd129983b)
>
> Executing Thread ID: 0x08a010003
>
> Executing Thread Name: IRQS
>
> This only seems to occur when I configure RTEMS to execute on both
> cores of the A9 processor (by setting #define
> CONFIGURE_MAXIMUM_PROCESSORS to 2). When I have #define
> CONFIGURE_MAXIMUM_PROCESSORS set to 1 the program runs as expected,
> connects to my TCP server and sends nominal data. Also, for what it's
> worth, the name of my task is not IRQS so I'm not sure why I keep
> getting this exception in the IRQS thread.
>
> My system.hdf file and MMU setup code look as follow:
>
> System.hdf:
>
>
> MMU Configuration file:
>
> *#include*
>
> *#include*
>
> *#include*
>
> *#include*
>
> *#include*
>
> BSP_START_DATA_SECTION*static**const*arm_cp15_start_section_config
>
> zynq_mmu_config_table[] = {
>
> ARMV7_CP15_START_DEFAULT_SECTIONS,
>
> {
>
> .begin = 0xE000U,
>
> .end = 0xE030U,
>
> .flags = ARMV7_MMU_DEVICE | ARM_MMU_SECT_S
>
> },{
>
> .begin = 0xF800U,
>
> .end = 0xF900U,
>
> .flags = ARMV7_MMU_DEVICE | ARM_MMU_SECT_S
>
> },{
>
> .begin = 0xU, /*RAM 0 START ADDR*/
>
> .end = 0x0002U, /*RAM 0 END ADDR*/
>
> .flags = ARMV7_MMU_DEVICE | ARM_MMU_SECT_S
>
> },{
>
> .begin = 0xU, /*RAM 1 START ADDR*/
>
> .end = 0xFDFFU, /*RAM 1 END ADDR*/
>
> .flags = ARMV7_MMU_DEVICE | ARM_MMU_SECT_S
>
> },{
>
> .begin = 0x4120U, /*AXI GPIO*/
>
> .end = 0x4120U, /*AXI GPIO*/
>
> .flags = ARMV7_MMU_DEVICE | ARM_MMU_SECT_S
>
> }
>
> };
>
> BSP_START_TEXT_SECTION *void**zynq_setup_mmu_and_cache*(*void*)
>
> {
>
> uint32_tctrl = arm_cp15_start_setup_mmu_and_cache(
>
> ARM_CP15_CTRL_A,
>
> ARM_CP15_CTRL_AFE | ARM_CP15_CTRL_Z
>
> );
>
> arm_cp15_start_setup_translation_table_and_enable_mmu_and_cache(
>
> ctrl,
>
> (uint32_t*) bsp_translation_table_base,
>
> ARM_MMU_DEFAULT_CLIENT_DOMAIN,
>
> &zynq_mmu_config_table[0],
>
> RTEMS_ARRAY_SIZE(zynq_mmu_config_table)
>
> );
>
> }
>
> Does anyone have an idea of as to what may be going on here?
>
> Thanks,
>
> Avi
>
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: Zynq RTEMS 5 SMP Crashing on call to connect in socket.h [Solved]
On 15/01/2019 08:24, Misra, Avinash wrote: Thank you for your response. I was using a custom scheduler configuration because of one of the RTEM smp examples I saw. How did you find the examples? Are they in the RTEMS smptests? Did you read the SMP chapter in the documentation https://docs.rtems.org/branches/master/c-user/symmetric_multiprocessing_services.html ? I ask because you should select a custom scheduler configuration only for specific reasons and this should be clear from the documentation. I didn't realize that it would end up affecting BSD and the networking protocol. FreeBSD introduced the Epoch Based Reclamation in version 12 and unfortunately it is not easy to support in RTEMS. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
