I kind of wonder if it has anything to do with compiler code generation; I don't remember if you checked whether -O[0,1,2,3] on the kernel changed anything. The appearance is so random, but when it does appear, it's stuck for that version (i.e. not just a race issue that is hard to repro).
Patrick On Thu, Dec 12, 2013 at 3:20 PM, Émeric MASCHINO <emeric.masch...@gmail.com>wrote: > Ben, > > I was not reporting this as a reproach, but simply to track down which > kernels work and which don't. From my records: > - 2.6.38: KO (*) see below > - 3.0.0-2: OK > - 3.1.0-1: KO > - 3.2.23: KO > - 3.2.35-2: OK > - 3.2.46-1+deb7u1: KO > - 3.10.11-1: OK > - 3.11.8-1: KO > - 3.11.10-1: KO > > About upstream, I still don't understand how is it that this problem > hasn't been talked about. I know I'm a bad programmer, but I would be > very surprised being the only one needing GDB on ia64 ;-) > > I don't know if upstream people are subscribed to this list. When I > asked on linux-ia64 which distro ia64 people are running [1], the only > answer I got was from Raúl Porcel, the Gentoo-ia64 maintainer, nothing > from Intel or hp developers. So I don't know how Linux/ia64 > development is managed. Are Intel and hp people using a custom distro? > Are they simply running Itanium systems? This is a legitimate question > as I don't remember that they ever commented on this issue. Is it that > they don't hit it? In fact, the only occurrence about this issue I can > find on the linux-ia64 list is one of my remark in a post about a > regression introduced with "Sanitize cmpxchg_futex_value_locked API" > patch [2]. (*) And this was during kernel 2.6.38 development cycle! > Bisecting back to such old kernel is simply impossible with today's > udev and because of accept4 syscall was missing in < 3.2.0-1 kernels. > > Also, as I reported some times ago [3], this issue is not specific to > Debian kernels. In fact, a given kernel version can break GDB or not, > depending upon its configuration (i.e. depending whether code is > statically built or built as modules). Once again, I didn't get any > comment on this, so don't know how I can help further: I'm not a > kernel developer and have no knowledge of ia64 internals, except what > I've read in "ia-64 linux kernel" book by David Mosberger and Stéphane > Eranian, with a lot of things far behind my understanding. And even if > I can go back as old as kernel 2.6.38, how to be sure that everything > was definitely working fine then or just being lucky because of a > working kernel configuration? > > Émeric > > > [1] http://marc.info/?l=linux-ia64&m=134858659916369&w=2 > [2] http://marc.info/?l=linux-ia64&m=133124040906499&w=2 > [3] http://lists.debian.org/debian-ia64/2013/09/msg00024.html > > 2013/12/11 Ben Hutchings <b...@decadent.org.uk>: > > On Tue, Dec 10, 2013 at 11:36:37PM +0100, Émeric MASCHINO wrote: > >> FYI, linux-image-3.11-2-mckinley 3.11.10-1 in today's Jessie updates > >> didn't change anything w.r.t. gdb problem. > > > > Of course it didn't. If you want ia64 fixed then you'll have to talk > > to upstream or fix it yourself. > > > > Ben. > > > > -- > > Ben Hutchings > > If God had intended Man to program, > > we'd have been born with serial I/O ports. > > > -- > To UNSUBSCRIBE, email to debian-ia64-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact > listmas...@lists.debian.org > Archive: > http://lists.debian.org/caa9xbm5h_sn+vgutc6pgswfrtay0ftapo1a-g6lq5xhee8...@mail.gmail.com > >
