All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thiemo Seufer <ths@networkno.de>
To: Pierre Palatin <pierre.palatin@m4tp.org>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] qemu/linux-user main.c
Date: Mon, 19 Mar 2007 21:10:13 +0000	[thread overview]
Message-ID: <20070319211013.GI28895@networkno.de> (raw)
In-Reply-To: <200703192146.24598.pierre.palatin@m4tp.org>

Pierre Palatin wrote:
> On Monday 19 March 2007 21:13:12 Thiemo Seufer wrote:
> > J. Mayer wrote:
> > > On Mon, 2007-03-19 at 12:16 +0000, Thiemo Seufer wrote:
> > > > CVSROOT:	/sources/qemu
> > > > Module name:	qemu
> > > > Changes by:	Thiemo Seufer <ths>	07/03/19 12:16:29
> > > >
> > > > Modified files:
> > > > 	linux-user     : main.c
> > > >
> > > > Log message:
> > > > 	Support -cpu selection for mips usermode emulation. Fix segfault when
> > > > 	dispaying the -cpu list help.
> > >
> > > Could you tell more about the segfault ?
> >
> > It segfaulted for me (on ppc/linux) after printing the help list.
> >
> > > exit is used at many other places without any problem and furthermore I
> > > did not experiment any crash while testing the PowerPC target with the
> > > initial patch, so ? (I'd really like to understand...)
> >
> > I didn't really debug it, but I noticed the other branch in the
> > conditional uses _exit() instead of exit(). With that change, the
> > segfault disappeared. I figure we have an atexit/on_exit call somwhere
> > which tries to use data which isn't initialized at that point.
> 
> Maybe that's related to the problem i've got (in 
> http://lists.gnu.org/archive/html/qemu-devel/2007-03/msg00110.html ).
>
> There is some piece of code in main.c which mess around libc initialization & 
> exit and were making my qemu-i386 segfault really early. It seems it was 
> designed to avoid a bug in some versions of glibc.
> I attach the simple patch I've made to avoid that. 
> It may need adjustements since I don't know enough about libc internals on 
> initialization to be sure that's the correct fix - I would be deeply 
> interested in some input/comments on this problem.
> 
> Pierre Palatin

> Index: linux-user/main.c
> ===================================================================
> --- linux-user/main.c	(révision 527)
> +++ linux-user/main.c	(copie de travail)
> @@ -44,7 +44,7 @@
>  
>  /* for recent libc, we add these dummy symbols which are not declared
>     when generating a linked object (bug in ld ?) */
> -#if (__GLIBC__ > 2 || (__GLIBC__ == 2 && __GLIBC_MINOR__ >= 3)) && !defined(CONFIG_STATIC)
> +#if (__GLIBC__ == 2 && __GLIBC_MINOR__ == 3) && !defined(CONFIG_STATIC)
>  long __preinit_array_start[0];
>  long __preinit_array_end[0];
>  long __init_array_start[0];

binutils' ld had a bug a while ago, this looks like a workaround for it
(which means the check for glibc is wrong, and there's no easy way to
do it right).

Commenting out that code made no difference to me.


Thiemo

  reply	other threads:[~2007-03-19 21:13 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-19 12:16 [Qemu-devel] qemu/linux-user main.c Thiemo Seufer
2007-03-19 19:46 ` J. Mayer
2007-03-19 20:13   ` Thiemo Seufer
2007-03-19 20:46     ` Pierre Palatin
2007-03-19 21:10       ` Thiemo Seufer [this message]
  -- strict thread matches above, loose matches on Subject: below --
2008-03-26 22:40 Paul Brook
2008-01-08 14:39 Thiemo Seufer
2007-11-20 15:22 Thiemo Seufer
2007-11-15 15:37 Fabrice Bellard
2007-11-15 15:27 Fabrice Bellard
2007-11-11 19:32 Fabrice Bellard
2007-11-11 17:22 Fabrice Bellard
2007-11-11 14:46 Fabrice Bellard
2007-11-08 14:01 Fabrice Bellard
2007-11-08 13:56 Fabrice Bellard
2007-11-03 13:22 Jocelyn Mayer
2007-07-07 20:46 Blue Swirl
2007-06-27 11:12 Thiemo Seufer
2007-06-21 22:55 Thiemo Seufer
2007-06-17 16:38 Thiemo Seufer
2007-06-01 23:50 Thiemo Seufer
2007-04-08  6:30 Blue Swirl
2007-03-19  8:08 Jocelyn Mayer
2006-11-04 16:46 Paul Brook
2006-10-23 21:31 Fabrice Bellard
2006-09-24 18:48 Fabrice Bellard
2006-06-14 13:37 Fabrice Bellard
2005-12-05 21:04 Fabrice Bellard
2005-11-21 23:30 Fabrice Bellard
2005-10-30 21:01 Fabrice Bellard
2005-04-23 18:01 Fabrice Bellard
2005-03-13 16:56 Fabrice Bellard
2005-02-19 17:25 Fabrice Bellard
2005-02-15 22:54 Fabrice Bellard

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=20070319211013.GI28895@networkno.de \
    --to=ths@networkno.de \
    --cc=pierre.palatin@m4tp.org \
    --cc=qemu-devel@nongnu.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.