new siginfo support doesn't build on glibc 2.2.2

new siginfo support doesn't build on glibc 2.2.2

[Doug Evans]

fyi, glibc 2.2.2 doesn't have si_timerid, si_overrun.  compilation of
amd64-linux-nat.c fails.

Dunno how old a glibc we intend to support for 7.0.

Re: new siginfo support doesn't build on glibc 2.2.2

[Pedro Alves]

On Monday 09 February 2009 21:07:41, Doug Evans wrote:
> fyi, glibc 2.2.2 doesn't have si_timerid, si_overrun.  compilation of
> amd64-linux-nat.c fails.

Bummer.  According to sigaction(2), those exist only since kernel
2.6.  Those are defines, we could #ifdef on them, assuming we're
ok with a gdb built on that platform and then moved to some more
recent glibc will not translate those fields.

I don't know if the siginfo layout in that version is the same
as defined by the gdbarch callback, or even if your glibc's siginfo_t
declaration matches your kernel's siginfo_t object layout --- there's
a history of breakage on these matters.

> Dunno how old a glibc we intend to support for 7.0.

Could you try ifdefing those fields, and see what comes out of
$_siginfo; and taking a peek at your headers, to see if we're
doing something reasonable?  We have a couple of siginfo related
testcases that may help as small test apps.

-- 
Pedro Alves

Re: new siginfo support doesn't build on glibc 2.2.2

[Mark Kettenis]

> From: Pedro Alves <pedro@codesourcery.com>
> Date: Mon, 9 Feb 2009 22:55:03 +0000
> 
> On Monday 09 February 2009 21:07:41, Doug Evans wrote:
> > fyi, glibc 2.2.2 doesn't have si_timerid, si_overrun.  compilation of
> > amd64-linux-nat.c fails.
> 
> Bummer.  According to sigaction(2), those exist only since kernel
> 2.6.  Those are defines, we could #ifdef on them, assuming we're
> ok with a gdb built on that platform and then moved to some more
> recent glibc will not translate those fields.

Isn't it fun having an OS where the kernel and C library are seperate
projects that are hardy ever fully in sync?

> I don't know if the siginfo layout in that version is the same
> as defined by the gdbarch callback, or even if your glibc's siginfo_t
> declaration matches your kernel's siginfo_t object layout --- there's
> a history of breakage on these matters.

I doubt there is actual breakage.  The total size of siginfo_t should
not have changed between kernel releases.  What may have happened is
that there have been new structs added to the union part of siginfo_t,
or that existing structs in there have been extended.