From owner-freebsd-alpha Wed Feb 14 16:46:42 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id 93E9A37B401 for ; Wed, 14 Feb 2001 16:46:38 -0800 (PST) Received: (from daemon@localhost) by smtp03.primenet.com (8.9.3/8.9.3) id RAA11695; Wed, 14 Feb 2001 17:43:31 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp03.primenet.com, id smtpdAAA.saGKw; Wed Feb 14 17:43:13 2001 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id RAA10115; Wed, 14 Feb 2001 17:46:10 -0700 (MST) From: Terry Lambert Message-Id: <200102150046.RAA10115@usr08.primenet.com> Subject: Re: unaligned access To: gallatin@cs.duke.edu (Andrew Gallatin) Date: Thu, 15 Feb 2001 00:46:04 +0000 (GMT) Cc: Peter.Blok@inter.NL.net, freebsd-alpha@FreeBSD.ORG In-Reply-To: <14986.54140.54832.224655@grasshopper.cs.duke.edu> from "Andrew Gallatin" at Feb 14, 2001 01:50:36 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > 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