Re: weird error messages
These look as if, given a map file, they ought to be simple to find and fix, without necessarily understanding the what the code does (assuming the Trap gives you enough information where to look in a map file). It sounds like the kind of 'black box debugging' that I've done for the last year or so (don't tell my boss I still don't understand what the code does).
>From your analysis it appears there are 2 solutions.
1) Create an copy of the bytes in a way that a simple ->member access can read without trapping.
2) Supply unaligned read/write (inline) functions/macros
Something along the lines of
#define READ_8U(addr) \
(*((addr)&~7)>>(((addr)&7)<<3) | \
(*((addr&~7)+1)<<(64-((addr)&7)<<3))
Which is quite probably bogus as I haven't thought about what endianness the data is.
These could be used to replace
u64 key = pPacket->key; /* unaligned trap */
with
u64 key = READ_8U(&pPacket->key); /* safe */
Do such inline function/macro definitions already exist somewhere (I find it very hard to believe they don't)? If so, then we're already armed with all the tools we need - perhaps one weekend we should all just grab a package and fix a trap each!
Phil
On Fri, 09 February 2001, Paul Slootman wrote:
> On Fri 09 Feb 2001, Paul Slootman wrote:
> >
> > I'll see if I can have a look at snort for this; I prefer Chris
>
> I've had a look at this :-)
>
> It's always the same with packages that examine raw network stuff.
> It's because the ethernet packet is snarfed, and then a pointer to
> e.g. the IP part is passed to some other function that thinks it
> has a pointer to a struct and tries to use that directly. I fix this
> by allocating a separate struct for this (which is automagically
> aligned properly), and then copy the data from the address given
> into the new struct via memcpy (which does it byte by byte
> (effectively), hence not needing the alignment (although I'm sure
> some optimization takes place)).
>
> I've identified a couple of places where this needed to be done.
> I've put up a test version (1.7-2.alpha.1) of snort at
> http://www.murphy.nl/~paul/debian/snort/ ; the deb itself is
> http://www.murphy.nl/~paul/debian/snort/snort_1.7-2.alpha.1_alpha.deb
>
> Please give any feedback (esp. any remaining unaligned accesses;
> the first hex number is important in finding the place in the
> source where the problem is). I may have introduced some wierdness
> somewhere, so also please check it's still doing what it should be :-)
> There may still be an unaligned access if you have token ring (yeah,
> right, like anyone still uses IP over token ring on an alpha :-)
>
>
> Paul Slootman
> --
> home: paul@wurtel.net http://www.wurtel.demon.nl/
> work: paul@murphy.nl http://www.murphy.nl/
> debian: paul@debian.org http://www.debian.org/
> isdn4linux: paul@isdn4linux.org http://www.isdn4linux.org/
>
>
> --
> To UNSUBSCRIBE, email to debian-alpha-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Mathematics should not have to involve martyrdom;
Support Eric Weisstein, see http://mathworld.wolfram.com
Find the best deals on the web at AltaVista Shopping!
http://www.shopping.altavista.com
Reply to: