[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#691576: GDB still broken with 3.11.10-1



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.maschino@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 <ben@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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/CAA9xbM5h_sn+vgUTC6PgswFRtaY0FTapO1a-G6LQ5xHEE8Xjw@mail.gmail.com



Reply to: