On Wednesday 14 April 2010 13:14:07 Denys Vlasenko wrote:
Are you saying that here:
# define move_from_unaligned16(v, u16p) (memcpy((v), (u16p), 2))
memcpy may be opportunistic and if u16p has type uin16_t,
memcpy will be optimized to assignment? If so, this
should be prevented from
Let me know whether this patch fixes all your problems.
It fixes my busybox / dnsd related problems. I didn't really expect it
to solve _all_ my problems ;-)
Am 20.04.2010 22:25, schrieb Denys Vlasenko:
On Sat, Apr 17, 2010 at 7:46 AM, Lars Reemts l...@reemts.de wrote:
Does it work if
On Sat, Apr 17, 2010 at 7:46 AM, Lars Reemts l...@reemts.de wrote:
Does it work if you add PACKED here in dnsd.c?
struct type_and_class {
uint16_t type PACKED;
uint16_t class PACKED;
};
No, but it does work with:
struct type_and_class {
uint16_t type;
Sorry, my mistake.
Denys Vlasenko schrieb:
On Thu, Apr 15, 2010 at 12:40 AM, Lars Reemts l...@reemts.de wrote:
So I went with slapping ALIGN4 on the byte array instead.
The ALIGN4 doesn't compile for me. gcc complains not to know the ALIGN4
macro. Had to change it to:
uint8_t
Does it work if you add PACKED here in dnsd.c?
struct type_and_class {
uint16_t type PACKED;
uint16_t class PACKED;
};
No, but it does work with:
struct type_and_class {
uint16_t type;
uint16_t class;
}PACKED;
Then the disassembler also shows some calls to
On Thu, Apr 15, 2010 at 12:40 AM, Lars Reemts l...@reemts.de wrote:
So I went with slapping ALIGN4 on the byte array instead.
The ALIGN4 doesn't compile for me. gcc complains not to know the ALIGN4
macro. Had to change it to:
uint8_t buf[MAX_PACK_LEN + 1] __attribute__ ((aligned (4)));
Look
On Wed, Apr 14, 2010 at 6:02 AM, Lars Reemts l...@reemts.de wrote:
Hello,
I'm using busybox on a AT91SAM9261 (arm920t) processor with gcc 4.3.4.
Yesterday I ran into some problems using dnsd. DNS queries from a
windows host were not properly decoded and hence not answered. Digging
into the
Are you saying that here:
# define move_from_unaligned16(v, u16p) (memcpy((v), (u16p), 2))
memcpy may be opportunistic and if u16p has type uin16_t,
memcpy will be optimized to assignment?
Definitely yes.
Please find a way which works for your arch and compiler,
and let me know. Parhaps
Unfortunately
# define move_from_unaligned16(v, u16p) {void* src=(void*)(u16p);memcpy((v),
src, 2);}
also didn't do it. The only solution I've found working is doing it the
hard way by hand:
# define move_from_unaligned16(v, u16p) do { \
*((uint8_t*)v) = *((uint8_t*)u16p); \
So I went with slapping ALIGN4 on the byte array instead.
The ALIGN4 doesn't compile for me. gcc complains not to know the ALIGN4
macro. Had to change it to:
uint8_t buf[MAX_PACK_LEN + 1] __attribute__ ((aligned (4)));
Denys Vlasenko schrieb:
On Wed, Apr 14, 2010 at 6:02 AM, Lars Reemts
Unfortunately
# define move_from_unaligned16(v, u16p) {void* src=(void*)(u16p);memcpy((v),
src, 2);}
also didn't do it. The only solution I've found working is doing it the
hard way by hand:
# define move_from_unaligned16(v, u16p) do { \
*((uint8_t*)v) = *((uint8_t*)u16p); \
On Wed, Apr 14, 2010 at 6:02 AM, Lars Reemts l...@reemts.de wrote:
Hello,
I'm using busybox on a AT91SAM9261 (arm920t) processor with gcc 4.3.4.
Yesterday I ran into some problems using dnsd. DNS queries from a
windows host were not properly decoded and hence not answered. Digging
into the
12 matches
Mail list logo
