Regarding Open Project
Hello Developers, This is Pravin Soni, new in open source, working at KRACKIN Technologies. I am willing to contribute in RTEMS. For a beginner, can you please suggest me some open and unmentioned projects or tickets according to you. I have seen rtems wiki page and i have gone through the quick start page and trying to setup environment for SPARS BSP. I also heard about "Electra" from one of my friend (Aditya Upadhyay) he is working for rtems posix compliance. I am having idea about C,C++,Python,Shell Script. Any help from you will be give me chance to take a step in RTEMS. Thanks & Regards Pravin Soni ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
LIBBSD TCPDUMP
I get a crash when running the tcpdump command in LIBBSD. It is due to the
following structure
struct stp_bpdu_ {
u_int8_t protocol_id[2];
u_int8_t protocol_version;
u_int8_t bpdu_type;
u_int8_t flags;
u_int8_t root_id[8];
u_int8_t root_path_cost[4];
u_int8_t bridge_id[8];
u_int8_t port_id[2];
u_int8_t message_age[2];
u_int8_t max_age[2];
u_int8_t hello_time[2];
u_int8_t forward_delay[2];
u_int8_t v1_length;
};
In the code, there is an access to the port_id field as follows:
EXTRACT_16BITS(&stp_bpdu->port_id). EXTRACT_16BITS calls ntohs() . Since the
address of "&stp_bpdu->port_id" is at an odd word (16 bit) boundary, an
exception is generated. What is the correct way to fix this? I was going to
update EXTRACT_16BITS to check for an odd boundary and fix it up before calling
ntohs().
Kevin Kirspel
Electrical Engineer - Sr. Staff
Idexx Roswell
235 Hembree Park Drive
Roswell GA 30076
Tel: (770)-510- ext. 81642
Direct: (770)-688-1642
Fax: (770)-510-4445
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
libbsd ofwbus activate resources issue
Hi, When i mount device module such as ti_scm, usb via simplebus not nexus, i got an error: *** LIBBSD MEDIA 1 TEST *** nexus0: ofwbus0: on nexus0 simplebus0: on ofwbus0 simplebus1: on simplebus0 simplebus2: mem 0x21-0x211fff on simpleb1 ti_scm0: mem 0-0x7ff on simplebus2 ti_scm0: could not allocate resources device_attach: ti_scm0 attach returned 6 I use gdb to debug it: (gdb) bt #0 _bsd_kobj_error_method () at ../../freebsd/sys/kern/subr_kobj.c:97 #1 0x8002763c in BUS_ACTIVATE_RESOURCE (_r=0x804fddd0, _rid=, _type=3, _child=0x804fd7a0, _dev=0x804f8dd8) at ../../rtemsbsd/include/rtems/bsd/local/bus_if.h:339 #2 _bsd_bus_activate_resource (dev=dev@entry=0x804fd7a0, type=type@entry=3, rid=, r=r@entry=0x804fddd0) at ../../freebsd/sys/kern/subr_bus.c:4504 #3 0x800034f4 in ofwbus_alloc_resource (bus=0x804f7428, child=0x804fd7a0, type=3, rid=0x804019ac , start=9224063442842802440, end=1155530752, count=1155547135, flags=2) at ../../freebsd/sys/dev/ofw/ofwbus.c:229 #4 0x800274d4 in BUS_ALLOC_RESOURCE (_flags=, _count=1, _end=18446744073709551615, _start=0, _rid=0x804019ac , _type=, _child=, _dev=) at ../../rtemsbsd/include/rtems/bsd/local/bus_if.h:310 #5 _bsd_bus_alloc_resource (flags=, count=1, end=18446744073709551615, start=0, rid=0x804019ac , type=, dev=0x804fd7a0) at ../../freebsd/sys/kern/subr_bus.c:4473 #6 bus_alloc_resource_any (flags=, rid=0x804019ac , type=, dev=0x804fd7a0) at ../../freebsd/sys/sys/bus.h:544 #7 _bsd_bus_alloc_resources (dev=dev@entry=0x804fd7a0, rs=0x804f8dd8, rs@entry=0x804019a8 , res=res@entry=0x804fd908) at ../../freebsd/sys/kern/subr_bus.c:4435 #8 0x80001664 in am335x_prcm_attach (dev=0x804fd7a0) at ../../freebsd/sys/arm/ti/am335x/am335x_prcm.c:438 #9 0x80025730 in DEVICE_ATTACH (dev=0x804fd7a0) at ../../rtemsbsd/include/rtems/bsd/local/device_if.h:180 #10 _bsd_device_attach (dev=dev@entry=0x804fd7a0) at ../../freebsd/sys/kern/subr_bus.c:2947 #11 0x800265f8 in _bsd_device_probe_and_attach (dev=dev@entry=0x804fd7a0) at ../../freebsd/sys/kern/subr_bus.c:2903 #12 0x800268fc in _bsd_bus_generic_attach (dev=dev@entry=0x804f8dd8) at ../../freebsd/sys/kern/subr_bus.c:3714 #13 0x8000248c in simplebus_attach (dev=0x804f8dd8) at ../../freebsd/sys/dev/fdt/simplebus.c:164 #14 0x80025730 in DEVICE_ATTACH (dev=0x804f8dd8) at ../../rtemsbsd/include/rtems/bsd/local/device_if.h:180 #15 _bsd_device_attach (dev=dev@entry=0x804f8dd8) at ../../freebsd/sys/kern/subr_bus.c:2947 #16 0x800265f8 in _bsd_device_probe_and_attach (dev=dev@entry=0x804f8dd8) at ../../freebsd/sys/kern/subr_bus.c:2903 #17 0x800268fc in _bsd_bus_generic_attach (dev=dev@entry=0x804f84d0) at ../../freebsd/sys/kern/subr_bus.c:3714 #18 0x8000248c in simplebus_attach (dev=0x804f84d0) at ../../freebsd/sys/dev/fdt/simplebus.c:164 #19 0x80025730 in DEVICE_ATTACH (dev=0x804f84d0) at ../../rtemsbsd/include/rtems/bsd/local/device_if.h:180 #20 _bsd_device_attach (dev=dev@entry=0x804f84d0) at ../../freebsd/sys/kern/subr_bus.c:2947 #21 0x800265f8 in _bsd_device_probe_and_attach (dev=dev@entry=0x804f84d0) at ../../freebsd/sys/kern/subr_bus.c:2903 #22 0x800268fc in _bsd_bus_generic_attach (dev=dev@entry=0x804f7428) at ../../freebsd/sys/kern/subr_bus.c:3714 #23 0x80003634 in ofwbus_attach (dev=0x804f7428) at ../../freebsd/sys/dev/ofw/ofwbus.c:181 #24 0x80025730 in DEVICE_ATTACH (dev=0x804f7428) at ../../rtemsbsd/include/rtems/bsd/local/device_if.h:180 #25 _bsd_device_attach (dev=dev@entry=0x804f7428) at ../../freebsd/sys/kern/subr_bus.c:2947 #26 0x800265f8 in _bsd_device_probe_and_attach (dev=dev@entry=0x804f7428) at ../../freebsd/sys/kern/subr_bus.c:2903 #27 0x800268fc in _bsd_bus_generic_attach (dev=) at ../../freebsd/sys/kern/subr_bus.c:3714 #28 0x80025730 in DEVICE_ATTACH (dev=0x804f72b0) at ../../rtemsbsd/include/rtems/bsd/local/device_if.h:180 #29 _bsd_device_attach (dev=dev@entry=0x804f72b0) at ../../freebsd/sys/kern/subr_bus.c:2947 #30 0x800265f8 in _bsd_device_probe_and_attach (dev=dev@entry=0x804f72b0) at ../../freebsd/sys/kern/subr_bus.c:2903 #31 0x80026d0c in _bsd_bus_generic_new_pass (dev=0x804f3ce0) at ../../freebsd/sys/kern/subr_bus.c:4000 #32 0x800252b4 in BUS_NEW_PASS (_dev=0x804f3ce0) at ../../rtemsbsd/include/rtems/bsd/local/bus_if.h:938 #33 _bsd_bus_set_pass (pass=2147483647) at ../../freebsd/sys/kern/subr_bus.c:987 #34 0x800b8c08 in _bsd_mi_startup () at ../../freebsd/sys/kern/init_main.c:306 #35 0x80082568 in rtems_bsd_initialize () at ../../rtemsbsd/rtems/rtems-kernel-init.c:158 #36 0x87c4 in Init (arg=) at ../../testsuite/include/rtems/bsd/test/default-network-init.h:271 #37 0x801899b0 in _Thread_Handler () at ../../../../../../rtems/c/src/../../cpukit/score/src/threadhandler.c:88 #38 0x80171258 i
Re: LIBBSD TCPDUMP
On Jul 1, 2017 9:01 AM, "Kirspel, Kevin" wrote:
I get a crash when running the tcpdump command in LIBBSD. It is due to the
following structure
struct stp_bpdu_ {
u_int8_t protocol_id[2];
u_int8_t protocol_version;
u_int8_t bpdu_type;
u_int8_t flags;
u_int8_t root_id[8];
u_int8_t root_path_cost[4];
u_int8_t bridge_id[8];
u_int8_t port_id[2];
u_int8_t message_age[2];
u_int8_t max_age[2];
u_int8_t hello_time[2];
u_int8_t forward_delay[2];
u_int8_t v1_length;
};
In the code, there is an access to the port_id field as follows:
EXTRACT_16BITS(&stp_bpdu->port_id). EXTRACT_16BITS calls ntohs() . Since
the address of “&stp_bpdu->port_id” is at an odd word (16 bit) boundary, an
exception is generated. What is the correct way to fix this? I was going
to update EXTRACT_16BITS to check for an odd boundary and fix it up before
calling ntohs().
There should be a bit in cp15 which determines is unaligned accesses are
enabled. Should be examples in other BSPs
--joel
Kevin Kirspel
Electrical Engineer - Sr. Staff
Idexx Roswell
235 Hembree Park Drive
Roswell GA 30076
Tel: (770)-510- ext. 81642 <(770)%20510->
Direct: (770)-688-1642 <(770)%20688-1642>
Fax: (770)-510-4445 <(770)%20510-4445>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: Regarding Open Project
On Jul 1, 2017 3:12 AM, "pravin soni" wrote: Hello Developers, This is Pravin Soni, new in open source, working at KRACKIN Technologies. I am willing to contribute in RTEMS. For a beginner, can you please suggest me some open and unmentioned projects or tickets according to you. I have seen rtems wiki page and i have gone through the quick start page and trying to setup environment for SPARS BSP. I also heard about "Electra" from one of my friend (Aditya Upadhyay) he is working for rtems posix compliance. I am having idea about C,C++,Python,Shell Script. There are many other RTEMS applications in space and on Earth besides Electra. It has been on missions from Venus to Jupiter. :) Any help from you will be give me chance to take a step in RTEMS. If you have a SPARC BSP running all the tests, then the easiest next step to contribute is to fix a warning. This is usually more about the process of submitting than the difficulty and gets you over the hump with git, submitting patches, etc. I think there is a warning on the master in psximfs02 (may be a similar name) that needs to be fixed. Beyond that, we always encourage folks to look for an area they are interested in. And match the task with how much time you are willing to devote. We are always happy to have new contributors. But RTEMS is a large enough project where you can find something you like. :) --joel Thanks & Regards Pravin Soni ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: LIBBSD TCPDUMP
On Sat, Jul 1, 2017 at 10:01 AM, Kirspel, Kevin wrote:
> I get a crash when running the tcpdump command in LIBBSD. It is due to the
> following structure
>
>
>
> struct stp_bpdu_ {
>
> u_int8_t protocol_id[2];
>
> u_int8_t protocol_version;
>
> u_int8_t bpdu_type;
>
> u_int8_t flags;
>
> u_int8_t root_id[8];
>
> u_int8_t root_path_cost[4];
>
>u_int8_t bridge_id[8];
>
> u_int8_t port_id[2];
>
> u_int8_t message_age[2];
>
> u_int8_t max_age[2];
>
> u_int8_t hello_time[2];
>
> u_int8_t forward_delay[2];
>
> u_int8_t v1_length;
>
> };
>
>
>
> In the code, there is an access to the port_id field as follows:
> EXTRACT_16BITS(&stp_bpdu->port_id). EXTRACT_16BITS calls ntohs() . Since
> the address of “&stp_bpdu->port_id” is at an odd word (16 bit) boundary, an
> exception is generated. What is the correct way to fix this? I was going
> to update EXTRACT_16BITS to check for an odd boundary and fix it up before
> calling ntohs().
>
That would probably be a more portable fix than allowing unaligned
accesses. I think the alignment should be made to the CPU_ALIGNMENT
macro.
>
>
> Kevin Kirspel
>
> Electrical Engineer - Sr. Staff
>
> Idexx Roswell
>
> 235 Hembree Park Drive
>
> Roswell GA 30076
>
> Tel: (770)-510- ext. 81642
>
> Direct: (770)-688-1642
>
> Fax: (770)-510-4445
>
>
>
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: LIBBSD TCPDUMP
On Jul 1, 2017 10:34 AM, "Gedare Bloom" wrote:
On Sat, Jul 1, 2017 at 10:01 AM, Kirspel, Kevin
wrote:
> I get a crash when running the tcpdump command in LIBBSD. It is due to
the
> following structure
>
>
>
> struct stp_bpdu_ {
>
> u_int8_t protocol_id[2];
>
> u_int8_t protocol_version;
>
> u_int8_t bpdu_type;
>
> u_int8_t flags;
>
> u_int8_t root_id[8];
>
> u_int8_t root_path_cost[4];
>
>u_int8_t bridge_id[8];
>
> u_int8_t port_id[2];
>
> u_int8_t message_age[2];
>
> u_int8_t max_age[2];
>
> u_int8_t hello_time[2];
>
> u_int8_t forward_delay[2];
>
> u_int8_t v1_length;
>
> };
>
>
>
> In the code, there is an access to the port_id field as follows:
> EXTRACT_16BITS(&stp_bpdu->port_id). EXTRACT_16BITS calls ntohs() . Since
> the address of “&stp_bpdu->port_id” is at an odd word (16 bit) boundary,
an
> exception is generated. What is the correct way to fix this? I was going
> to update EXTRACT_16BITS to check for an odd boundary and fix it up before
> calling ntohs().
>
That would probably be a more portable fix than allowing unaligned
accesses. I think the alignment should be made to the CPU_ALIGNMENT
macro.
Can't you also just pull it out a byte at a time, form the net version and
then ntohs()?
That's what I coded recently in some marahalling code.
>
>
> Kevin Kirspel
>
> Electrical Engineer - Sr. Staff
>
> Idexx Roswell
>
> 235 Hembree Park Drive
>
> Roswell GA 30076
>
> Tel: (770)-510- ext. 81642
>
> Direct: (770)-688-1642
>
> Fax: (770)-510-4445
>
>
>
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
RE: LIBBSD TCPDUMP
This is how I fixed it. I did similar things for EXTRACT_32BITS and
EXTRACT_64BITS.
static inline u_int16_t
EXTRACT_16BITS(const void *p)
{
#if defined(__arm__) && defined(__rtems__)
if(((uint32_t)p % 2) != 0) {
u_int16_t value;
u_int8_t *ptr = (u_int8_t *)&value;
ptr[0] = ((const u_int8_t *)p)[0];
ptr[1] = ((const u_int8_t *)p)[1];
p = &value;
}
#endif /* __rtems__ */
return ((u_int16_t)ntohs(*(const u_int16_t *)(p)));
}
Kevin Kirspel
Electrical Engineer - Sr. Staff
Idexx Roswell
235 Hembree Park Drive
Roswell GA 30076
Tel: (770)-510- ext. 81642
Direct: (770)-688-1642
Fax: (770)-510-4445
From: Joel Sherrill [mailto:j...@rtems.org]
Sent: Saturday, July 01, 2017 11:39 AM
To: Gedare Bloom
Cc: rtems-de...@rtems.org ; Kirspel, Kevin
Subject: Re: LIBBSD TCPDUMP
On Jul 1, 2017 10:34 AM, "Gedare Bloom"
mailto:ged...@rtems.org>> wrote:
On Sat, Jul 1, 2017 at 10:01 AM, Kirspel, Kevin
mailto:kevin-kirs...@idexx.com>> wrote:
> I get a crash when running the tcpdump command in LIBBSD. It is due to the
> following structure
>
>
>
> struct stp_bpdu_ {
>
> u_int8_t protocol_id[2];
>
> u_int8_t protocol_version;
>
> u_int8_t bpdu_type;
>
> u_int8_t flags;
>
> u_int8_t root_id[8];
>
> u_int8_t root_path_cost[4];
>
>u_int8_t bridge_id[8];
>
> u_int8_t port_id[2];
>
> u_int8_t message_age[2];
>
> u_int8_t max_age[2];
>
> u_int8_t hello_time[2];
>
> u_int8_t forward_delay[2];
>
> u_int8_t v1_length;
>
> };
>
>
>
> In the code, there is an access to the port_id field as follows:
> EXTRACT_16BITS(&stp_bpdu->port_id). EXTRACT_16BITS calls ntohs() . Since
> the address of “&stp_bpdu->port_id” is at an odd word (16 bit) boundary, an
> exception is generated. What is the correct way to fix this? I was going
> to update EXTRACT_16BITS to check for an odd boundary and fix it up before
> calling ntohs().
>
That would probably be a more portable fix than allowing unaligned
accesses. I think the alignment should be made to the CPU_ALIGNMENT
macro.
Can't you also just pull it out a byte at a time, form the net version and then
ntohs()?
That's what I coded recently in some marahalling code.
>
>
> Kevin Kirspel
>
> Electrical Engineer - Sr. Staff
>
> Idexx Roswell
>
> 235 Hembree Park Drive
>
> Roswell GA 30076
>
> Tel: (770)-510- ext. 81642
>
> Direct: (770)-688-1642
>
> Fax: (770)-510-4445
>
>
>
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH] Fix GDB build on ArchLinux
From: Andreas Kölbl
Archlinux provides both, libguile v2.0 and v2.2. GDB states in
configuration its compatibility with both versions of libguile which is
false. The SCM_port interface of libguile was removed in v2.2 and
therefore breaks GDB as a user.
RTEMS does not use libguile and therefore it can be compiled without
support.
https://sourceware.org/bugzilla/show_bug.cgi?id=21104
Close #3054.
---
source-builder/config/gdb-7-1.cfg | 1 +
1 file changed, 1 insertion(+)
diff --git a/source-builder/config/gdb-7-1.cfg
b/source-builder/config/gdb-7-1.cfg
index 21591b5..a045c3b 100644
--- a/source-builder/config/gdb-7-1.cfg
+++ b/source-builder/config/gdb-7-1.cfg
@@ -119,6 +119,7 @@ BuildRoot: %{_tmppath}/%{name}-root-%(%{__id_u} -n)
%{?gdb-sim-options:%{gdb-sim-options}} \
--without-zlib \
--with-expat \
+--with-guile=no \
%{!?without_python:%{with_python_option}} \
--prefix=%{_prefix} --bindir=%{_bindir} \
--exec-prefix=%{_exec_prefix} \
--
2.13.2
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: LIBBSD TCPDUMP
On Sat, Jul 1, 2017 at 11:49 AM, Kirspel, Kevin wrote:
> This is how I fixed it. I did similar things for EXTRACT_32BITS and
> EXTRACT_64BITS.
>
>
>
> static inline u_int16_t
>
> EXTRACT_16BITS(const void *p)
>
> {
>
> #if defined(__arm__) && defined(__rtems__)
>
> if(((uint32_t)p % 2) != 0) {
>
> u_int16_t value;
>
> u_int8_t *ptr = (u_int8_t *)&value;
>
> ptr[0] = ((const u_int8_t *)p)[0];
>
> ptr[1] = ((const u_int8_t *)p)[1];
>
> p = &value;
>
Is it correct to assign a pointer to a block-scoped variable here? It
looks suspect to me. I'd at least put the declaration of 'value'
before the block here.
> }
>
> #endif /* __rtems__ */
>
> return ((u_int16_t)ntohs(*(const u_int16_t *)(p)));
>
> }
>
>
>
> Kevin Kirspel
>
> Electrical Engineer - Sr. Staff
>
> Idexx Roswell
>
> 235 Hembree Park Drive
>
> Roswell GA 30076
>
> Tel: (770)-510- ext. 81642
>
> Direct: (770)-688-1642
>
> Fax: (770)-510-4445
>
>
>
> From: Joel Sherrill [mailto:j...@rtems.org]
> Sent: Saturday, July 01, 2017 11:39 AM
> To: Gedare Bloom
> Cc: rtems-de...@rtems.org ; Kirspel, Kevin
>
> Subject: Re: LIBBSD TCPDUMP
>
>
>
>
>
>
>
> On Jul 1, 2017 10:34 AM, "Gedare Bloom" wrote:
>
> On Sat, Jul 1, 2017 at 10:01 AM, Kirspel, Kevin
> wrote:
>> I get a crash when running the tcpdump command in LIBBSD. It is due to
>> the
>> following structure
>>
>>
>>
>> struct stp_bpdu_ {
>>
>> u_int8_t protocol_id[2];
>>
>> u_int8_t protocol_version;
>>
>> u_int8_t bpdu_type;
>>
>> u_int8_t flags;
>>
>> u_int8_t root_id[8];
>>
>> u_int8_t root_path_cost[4];
>>
>>u_int8_t bridge_id[8];
>>
>> u_int8_t port_id[2];
>>
>> u_int8_t message_age[2];
>>
>> u_int8_t max_age[2];
>>
>> u_int8_t hello_time[2];
>>
>> u_int8_t forward_delay[2];
>>
>> u_int8_t v1_length;
>>
>> };
>>
>>
>>
>> In the code, there is an access to the port_id field as follows:
>> EXTRACT_16BITS(&stp_bpdu->port_id). EXTRACT_16BITS calls ntohs() . Since
>> the address of “&stp_bpdu->port_id” is at an odd word (16 bit) boundary,
>> an
>> exception is generated. What is the correct way to fix this? I was going
>> to update EXTRACT_16BITS to check for an odd boundary and fix it up before
>> calling ntohs().
>>
>
> That would probably be a more portable fix than allowing unaligned
> accesses. I think the alignment should be made to the CPU_ALIGNMENT
> macro.
>
>
>
> Can't you also just pull it out a byte at a time, form the net version and
> then ntohs()?
>
>
>
> That's what I coded recently in some marahalling code.
>
>
>
>
>
>>
>>
>> Kevin Kirspel
>>
>> Electrical Engineer - Sr. Staff
>>
>> Idexx Roswell
>>
>> 235 Hembree Park Drive
>>
>> Roswell GA 30076
>>
>> Tel: (770)-510- ext. 81642
>>
>> Direct: (770)-688-1642
>>
>> Fax: (770)-510-4445
>>
>>
>>
>>
>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
RE: LIBBSD TCPDUMP
No. I fixed that after I noticed the data was invalid during testing. I moved
the variable declaration outside of the if statement and now the data is
correct.
Kevin Kirspel
Electrical Engineer - Sr. Staff
Idexx Roswell
235 Hembree Park Drive
Roswell GA 30076
Tel: (770)-510- ext. 81642
Direct: (770)-688-1642
Fax: (770)-510-4445
-Original Message-
From: ged...@gwmail.gwu.edu [mailto:ged...@gwmail.gwu.edu] On Behalf Of Gedare
Bloom
Sent: Saturday, July 01, 2017 1:30 PM
To: Kirspel, Kevin
Cc: j...@rtems.org; rtems-de...@rtems.org
Subject: Re: LIBBSD TCPDUMP
On Sat, Jul 1, 2017 at 11:49 AM, Kirspel, Kevin wrote:
> This is how I fixed it. I did similar things for EXTRACT_32BITS and
> EXTRACT_64BITS.
>
>
>
> static inline u_int16_t
>
> EXTRACT_16BITS(const void *p)
>
> {
>
> #if defined(__arm__) && defined(__rtems__)
>
> if(((uint32_t)p % 2) != 0) {
>
> u_int16_t value;
>
> u_int8_t *ptr = (u_int8_t *)&value;
>
> ptr[0] = ((const u_int8_t *)p)[0];
>
> ptr[1] = ((const u_int8_t *)p)[1];
>
> p = &value;
>
Is it correct to assign a pointer to a block-scoped variable here? It looks
suspect to me. I'd at least put the declaration of 'value'
before the block here.
> }
>
> #endif /* __rtems__ */
>
> return ((u_int16_t)ntohs(*(const u_int16_t *)(p)));
>
> }
>
>
>
> Kevin Kirspel
>
> Electrical Engineer - Sr. Staff
>
> Idexx Roswell
>
> 235 Hembree Park Drive
>
> Roswell GA 30076
>
> Tel: (770)-510- ext. 81642
>
> Direct: (770)-688-1642
>
> Fax: (770)-510-4445
>
>
>
> From: Joel Sherrill [mailto:j...@rtems.org]
> Sent: Saturday, July 01, 2017 11:39 AM
> To: Gedare Bloom
> Cc: rtems-de...@rtems.org ; Kirspel, Kevin
>
> Subject: Re: LIBBSD TCPDUMP
>
>
>
>
>
>
>
> On Jul 1, 2017 10:34 AM, "Gedare Bloom" wrote:
>
> On Sat, Jul 1, 2017 at 10:01 AM, Kirspel, Kevin
>
> wrote:
>> I get a crash when running the tcpdump command in LIBBSD. It is due
>> to the following structure
>>
>>
>>
>> struct stp_bpdu_ {
>>
>> u_int8_t protocol_id[2];
>>
>> u_int8_t protocol_version;
>>
>> u_int8_t bpdu_type;
>>
>> u_int8_t flags;
>>
>> u_int8_t root_id[8];
>>
>> u_int8_t root_path_cost[4];
>>
>>u_int8_t bridge_id[8];
>>
>> u_int8_t port_id[2];
>>
>> u_int8_t message_age[2];
>>
>> u_int8_t max_age[2];
>>
>> u_int8_t hello_time[2];
>>
>> u_int8_t forward_delay[2];
>>
>> u_int8_t v1_length;
>>
>> };
>>
>>
>>
>> In the code, there is an access to the port_id field as follows:
>> EXTRACT_16BITS(&stp_bpdu->port_id). EXTRACT_16BITS calls ntohs() .
>> Since the address of “&stp_bpdu->port_id” is at an odd word (16 bit)
>> boundary, an exception is generated. What is the correct way to fix
>> this? I was going to update EXTRACT_16BITS to check for an odd
>> boundary and fix it up before calling ntohs().
>>
>
> That would probably be a more portable fix than allowing unaligned
> accesses. I think the alignment should be made to the CPU_ALIGNMENT
> macro.
>
>
>
> Can't you also just pull it out a byte at a time, form the net version
> and then ntohs()?
>
>
>
> That's what I coded recently in some marahalling code.
>
>
>
>
>
>>
>>
>> Kevin Kirspel
>>
>> Electrical Engineer - Sr. Staff
>>
>> Idexx Roswell
>>
>> 235 Hembree Park Drive
>>
>> Roswell GA 30076
>>
>> Tel: (770)-510- ext. 81642
>>
>> Direct: (770)-688-1642
>>
>> Fax: (770)-510-4445
>>
>>
>>
>>
>
>> ___
>> devel mailing list
>> devel@rtems.org
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.rtems.org_m
>> ailman_listinfo_devel&d=DwIFaQ&c=2do6VJGs3LvEOe4OFFM1bA&r=HDiJ93ANMEQ
>> 32G5JGdpyUxbdebuwKHBbeiHMr3RbR74&m=ZD1dtkTMUak_NH2kvhh9fcWsBvl09av5rA
>> xPKDDt1ac&s=QxnRQLVQGW81f8ARsKfj1Hd7M4JNXV0oc_WjhT5dOHw&e=
> ___
> devel mailing list
> devel@rtems.org
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.rtems.org_ma
> ilman_listinfo_devel&d=DwIFaQ&c=2do6VJGs3LvEOe4OFFM1bA&r=HDiJ93ANMEQ32
> G5JGdpyUxbdebuwKHBbeiHMr3RbR74&m=ZD1dtkTMUak_NH2kvhh9fcWsBvl09av5rAxPKDDt1ac&s=QxnRQLVQGW81f8ARsKfj1Hd7M4JNXV0oc_WjhT5dOHw&e=
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
