From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3356 invoked by alias); 9 Jun 2002 15:26:31 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 3347 invoked from network); 9 Jun 2002 15:26:29 -0000 Received: from unknown (HELO walton.kettenis.dyndns.org) (213.93.114.42) by sources.redhat.com with SMTP; 9 Jun 2002 15:26:29 -0000 Received: from elgar.kettenis.dyndns.org (elgar.kettenis.dyndns.org [192.168.0.2]) by walton.kettenis.dyndns.org (8.11.6/8.11.6) with ESMTP id g59FQQs00543 for ; Sun, 9 Jun 2002 17:26:26 +0200 (CEST) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: (from kettenis@localhost) by elgar.kettenis.dyndns.org (8.11.6/8.11.6) id g59FQQ405652; Sun, 9 Jun 2002 17:26:26 +0200 (CEST) (envelope-from kettenis) Date: Sun, 09 Jun 2002 08:26:00 -0000 From: Mark Kettenis Message-Id: <200206091526.g59FQQ405652@elgar.kettenis.dyndns.org> To: gdb-patches@sources.redhat.com Subject: [PATCH/RFA]: Adapt solib-svr4.c for recent gdbarch_data changes X-SW-Source: 2002-06/txt/msg00141.txt.bz2 Discovered this moring that my gdb was crashing. Seems like we have an initialization cycle here. I think that after Andrew's patch we can simplify init_fetch_link_map_offsets as in the attached patch. OK to check this in? Mark Index: ChangeLog from Mark Kettenis * solib-svr4.c (init_fetch_link_map_offsets): Simply return legacy_fetch_link_map_offsets. Adjust comment to reflect reality after Andrew's 2002-06-08 gdbarch change. Index: solib-svr4.c =================================================================== RCS file: /cvs/src/src/gdb/solib-svr4.c,v retrieving revision 1.25 diff -u -p -r1.25 solib-svr4.c --- solib-svr4.c 12 May 2002 01:02:58 -0000 1.25 +++ solib-svr4.c 9 Jun 2002 15:22:10 -0000 @@ -1318,24 +1318,20 @@ set_solib_svr4_fetch_link_map_offsets (s set_gdbarch_data (gdbarch, fetch_link_map_offsets_gdbarch_data, flmo); } -/* Initialize the architecture specific link_map_offsets fetcher. - This is called after _gdbarch_init() has set up its struct - gdbarch for the new architecture, so care must be taken to use the - value set by set_solib_svr4_fetch_link_map_offsets(), above. We - do, however, attempt to provide a reasonable alternative (for - native targets anyway) if the _gdbarch_init() fails to call +/* Initialize the architecture-specific link_map_offsets fetcher. + This is called after _gdbarch_init() has set up its `struct + gdbarch' for the new architecture, and is only called if the + link_map_offsets fetcher isn't already initialized (which is + usually done by calling set_solib_svr4_fetch_link_map_offsets() + above in _gdbarch_init()). Therefore we attempt to provide a + reasonable alternative (for native targets anyway) if the + _gdbarch_init() fails to call set_solib_svr4_fetch_link_map_offsets(). */ static void * init_fetch_link_map_offsets (struct gdbarch *gdbarch) { - struct link_map_offsets *(*flmo) = - gdbarch_data (gdbarch, fetch_link_map_offsets_gdbarch_data); - - if (flmo == NULL) - return legacy_fetch_link_map_offsets; - else - return flmo; + return legacy_fetch_link_map_offsets; } static struct target_so_ops svr4_so_ops;