Date: Thu, 15 Feb 2001 12:59:00 +0100 From: "Peter Blok" <Peter.Blok@inter.NL.net> To: "'Terry Lambert'" <tlambert@primenet.com>, "'Andrew Gallatin'" <gallatin@cs.duke.edu> Cc: <Peter.Blok@inter.NL.net>, <freebsd-alpha@FreeBSD.ORG> Subject: RE: unaligned access Message-ID: <000001c09746$af96e2a0$8a02a8c0@ntpc> In-Reply-To: <200102150046.RAA10115@usr08.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Terry, and others. Thanks for the hints. One big cause was the embedded alloc routines, that doesn't do aligning. The next buffer allocated was unaligned, because the previous size was unaligned. I haven't looked closely enough to the structures. I also had one unaligned access in a varargs construction. Haven't found the cause yet. Peter -----Original Message----- From: Terry Lambert [mailto:tlambert@primenet.com] Sent: Thursday, February 15, 2001 01:46 To: Andrew Gallatin Cc: Peter.Blok@inter.NL.net; freebsd-alpha@FreeBSD.ORG Subject: Re: unaligned access > > I am trying to port mpd-netgraph to alpha, but i'm getting a > > lot of uac's. I am trying to use gdb, but I am not used to > > gdb. When I try to lookup the address it tells me it is > > outside the map. > > > > Is it possible to make it core dump instead of this warning? > > It would be nice if you can say: run this command and core > > dump on uac. > > > > Are tools available to determine in which function the uac > > takes place? I can make something myself with perl and nm, > > but if there is already something out there? > > > > Which compiler options bring this up at compile time? > > I don't know what mpd netgraph is. Can you elaborate further? Is the > kernel crashing, or is it a userland app? > > If it is a userland app, try running uap -s prior to invoking gdb. > Then run gdb on the app. You should get a SIGBUS at the PC of the > unaligned access. If gdb misbehaves, try increasing the size of the > heuristic-fence-post. Eg: > > (gdb) set heuristic-fence-post 0xffffffffffffffff The mpd program is Archie's multiplink PPP daemon; I'm pretty sure he had a pure kernel version released before he left Whistle, didn't he? It has to be the user space stuff, or it would be a panic, and he probably would be unable to use gdb. The "uap -s" program will work. It is a single instance overrride for the command argument. Without the gdb involved, it will core dump (which I've always found a lot more useful than stepping through with gdb, for all but one problem, over the years). There is also a sysctl, which will turn off the unaligned access trap fixup, and crash the program; I don't know why fixup is the default these days. Apparently, mpd hates the fixup process, since you'd expect it to work. Since the Alpha has x86 byte order, I'd suggest that the structure where data is having its unaligned dereference is probably a structure element dereference off a pointer cast from a character buffer. Look for your bug to go away if you use a "#pragma pack(1)" around the structure declarations used by the program. If the data is naturally aligned, and it's just the character buffer that's being cast that's the problem (been too long since I've had to read entrails in the PPP code, sorry), then you should be able to get away with creating an aligned buffer to which you copy the character buf data, prior to dereference. Even if you change the packing, and rely on the fixup, or you use an aligned buffer that you copy data into from an unaligned one, I suspect that you will still end up with unaligned fixups (I can't believe the PPP designers thought that far ahead). Getting rid of the unaligned fixups will probably end up being a bear. This may already be there, since I'm running rather old Alpha code (multia didn't work again until recently, and SMP work means "Stable Machine Precluded" to me), but it might be useful to add a "uap" argument that will suppress the printing of the meessages on a per process basis (sort of the opposite of the "cause a segmentation fault" flag). This would let the console be usable for things like CVSup of new code, when the process that provides yor connection to the network is faulting all over the place, and you need to download new code for it. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?000001c09746$af96e2a0$8a02a8c0>