From: Matthew Wilcox <willy@debian.org>
To: Randolph Chung <randolph@tausq.org>
Cc: parisc-linux@lists.parisc-linux.org
Subject: Re: [parisc-linux] more on canonicalize_funcptr_for_compare
Date: Wed, 14 May 2003 14:46:50 +0100 [thread overview]
Message-ID: <20030514134650.GC6859@parcelfarce.linux.theplanet.co.uk> (raw)
In-Reply-To: <20030514055225.GJ548@tausq.org>
On Tue, May 13, 2003 at 10:52:25PM -0700, Randolph Chung wrote:
> The latest glibc on hppa (2.3.1-17) was compiled with a gcc-3.2 which
> has the __canonicalize_funcptr_for_compare patch backported from gcc-3.3
> ... with this new version, some programs will die on startup (e.g. vim).
> I traced to a segfault in __canonicalize_funcptr_for_compare.
>
> The testcase below illustrates the problem:
>
> =====
> typedef void (*func_t)(void);
>
> #define N ((func_t)2)
>
> void foo(void) {};
>
> int main(int argc, char **argv)
> {
> return (foo == N);
> }
> =====
>
> this program segfaults when run with:
>
> (gdb) run
> Starting program: /home/tausq/sig
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x00010530 in __canonicalize_funcptr_for_compare ()
> (gdb) bt
> #0 0x00010530 in __canonicalize_funcptr_for_compare ()
> #1 0x000104bc in main (argc=1, argv=0xfaf001b8) at sig.c:9
>
> it seems like the 2 in the constant (N) confuses the comparision
> routine. If I change it to 1, everything is ok.... I don't really
> understand this tho, because the code for __c_f_f_c has something like:
>
> if ((int) fptr == -1 || (unsigned int) fptr < 4096 || !((int) fptr & 2))
> return (unsigned int) fptr;
>
> so, why doesn't that match the second || case and exit? (gdb
> disassmbly shows that the code tries to dereference the fptr argument
> and segfaults)
Even if this were fixed, it seems like a quality of implementation issue.
Basically, we're saying that if none of these conditions are met, it's
safe to dereference this pointer, and I'm sure we'll find people stuffing
other magic values into pointers.
I see three options:
1) Continue with this, accepting that some badly written software won't
run.
2) Install a signal handler that handles the segfault (we can lose two of
the tests this way, so it'll be faster in the common case)
3) Change the ABI. Make it so we always have unique PLabels. Recompile
anything necessary.
--
"It's not Hollywood. War is real, war is primarily not about defeat or
victory, it is about death. I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk
next prev parent reply other threads:[~2003-05-14 13:46 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-05-14 5:52 [parisc-linux] more on canonicalize_funcptr_for_compare Randolph Chung
2003-05-14 13:46 ` Matthew Wilcox [this message]
2003-05-14 16:43 ` John David Anglin
2003-05-14 15:04 ` Randolph Chung
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20030514134650.GC6859@parcelfarce.linux.theplanet.co.uk \
--to=willy@debian.org \
--cc=parisc-linux@lists.parisc-linux.org \
--cc=randolph@tausq.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox