[commit/AIX] Fix error when loading core file

[commit/AIX] Fix error when loading core file

[Joel Brobecker]

[-- Attachment #1: Type: text/plain, Size: 1259 bytes --]

Hello,

We noticed the following problem with gdb-6.6 when trying to load
a core file on AIX:

        (gdb) core core
        ptrace ldinfo: No such process.

This is the cause of 2 FAILS in corefile.exp.

I think the problem started when we introduced post_create_inferior.
This causes us to call the SOLIB_CREATE_INFERIOR_HOOK, which in our
case is defined as a call to xcoff_relocate_symtab. I haven't really
checked with older versions of GDB because rebuilding GDB on AIX is
mighty slow, but it very much looks like this function was not called
in the case of core files before. This function is assuming a live process,
not a core file. So what I did was do an early return when debugging
a core file.

What this made me realize, however, is that we should really be
converting the AIX port to using the target_so_ops. I'll try to do
that soon. In the meantime, the attached patch should be good enough.

2007-05-19  Joel Brobecker  <brobecker@adacore.com>

        * rs6000-nat.c (xcoff_relocate_symtab): Do nothing if debugging
        a core file. Add comment in the function description.

Tested on ppc-aix, fixes:

        gdb.base/corefile.exp: args: execfile -core=corefile
        gdb.base/corefile.exp: core-file command

Committed.

-- 
Joel

[-- Attachment #2: aix-core.diff --]
[-- Type: text/plain, Size: 856 bytes --]

Index: rs6000-nat.c
===================================================================
RCS file: /cvs/src/src/gdb/rs6000-nat.c,v
retrieving revision 1.70
diff -u -p -r1.70 rs6000-nat.c
--- rs6000-nat.c	11 May 2007 19:55:20 -0000	1.70
+++ rs6000-nat.c	18 May 2007 22:17:46 -0000
@@ -1016,7 +1016,9 @@ rs6000_create_inferior (char *exec_file,
 
 \f
 /* xcoff_relocate_symtab -      hook for symbol table relocation.
-   also reads shared libraries.  */
+   
+   This is only applicable to live processes, and is a no-op when
+   debugging a core file.  */
 
 void
 xcoff_relocate_symtab (unsigned int pid)
@@ -1028,6 +1030,9 @@ xcoff_relocate_symtab (unsigned int pid)
   int ldisize = arch64 ? sizeof (ldi->l64) : sizeof (ldi->l32);
   int size;
 
+  if (ptid_equal (inferior_ptid, null_ptid))
+    return;
+
   do
     {
       size = load_segs * ldisize;

Re: [commit/AIX] Fix error when loading core file

[Ulrich Weigand]

Joel Brobecker wrote:

> I think the problem started when we introduced post_create_inferior.
> This causes us to call the SOLIB_CREATE_INFERIOR_HOOK, which in our
> case is defined as a call to xcoff_relocate_symtab. I haven't really
> checked with older versions of GDB because rebuilding GDB on AIX is
> mighty slow, but it very much looks like this function was not called
> in the case of core files before. This function is assuming a live process,
> not a core file. So what I did was do an early return when debugging
> a core file.

Yes, if you look at the SOLIB_ADD definition:

#define SOLIB_ADD(a, b, c, d)   \
  if (PIDGET (inferior_ptid))   \
    /* Attach to process.  */  \
    xcoff_relocate_symtab (PIDGET (inferior_ptid)); \
  else          \
    /* Core file.  */ \
    xcoff_relocate_core (c);

it is clear that the _symtab version is intended to be called only
in the case of live process.

It looks like something changed to get SOLIB_CREATE_INFERIOR_HOOK
now invoked as well ...


> What this made me realize, however, is that we should really be
> converting the AIX port to using the target_so_ops. I'll try to do
> that soon. In the meantime, the attached patch should be good enough.

Yes, I noticed that as well.  I had already started to do that, but
got side-tracked by other stuff in the meantime.  One problem is that
the ldinfo ptrace call that is required to get at the list of loaded
shared libraries is really a native-only call.

I'd thought of defining a TARGET_OBJECT_LDINFO xfer_partial object
that reflects the contents of the ldinfo, and use this in the
implementation of a (platform-independent) solib-aix.c file.
The rs6000 native target and the core file support would need to
be extended to supply that object.

Once rs6000 uses a proper target_so_ops shared library handling, 
all the special stuff ("vmap", DEPRECECATED_IBM6000_TARGET,
xcoffsolib.c) should go away ...


I'll try to get back to doing this, but it'll be some time.  If
you want to work at it earlier, that would certainly be welcome.
Attached below is the current version of my new solib-aix.c file
-- note that this is work in progress that doesn't even compile
at this point, but if any of it is helpful, feel free to use it
as a base for your work.

Bye,
Ulrich


/* Handle AIX shared libraries for GDB, the GNU Debugger.

   Copyright (C) 2007 Free Software Foundation, Inc.

   This file is part of GDB.

   This program is free software; you can redistribute it and/or modify
   it under the terms of the GNU General Public License as published by
   the Free Software Foundation; either version 2 of the License, or
   (at your option) any later version.

   This program is distributed in the hope that it will be useful,
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
   GNU General Public License for more details.

   You should have received a copy of the GNU General Public License
   along with this program; if not, write to the Free Software
   Foundation, Inc., 51 Franklin Street, Fifth Floor,
   Boston, MA 02110-1301, USA.  */

#include "defs.h"

#include "symtab.h"
#include "bfd.h"
#include "symfile.h"
#include "objfiles.h"
#include "gdbcore.h"
#include "target.h"
#include "inferior.h"

#include "gdb_assert.h"

#include "solist.h"
#include "solib.h"

#include "bfd-target.h"
#include "exec.h"


/* The LDINFO data structure has the following layout:

                     32-bit     64-bit
    ldinfo_next       0 4        0 4
    ldinfo_fd         4 4        8 4
    ldinfo_textorg    8 4       16 8
    ldinfo_textsize  12 4       24 8
    ldinfo_dataorg   16 4       32 8
    ldinfo_datasize  20 4       40 8
    ldinfo_filename  24 -       48 -

   The following helper macros allow to access that structure
   without referring to AIX header files.  */

#define ldinfo_next(ldinfo, wordsize) \
 ((unsigned int) extract_unsigned_integer ((ldinfo), 4))

#define ldinfo_fd(ldinfo, wordsize) \
 ((int) extract_signed_integer ((ldinfo) + (wordsize), 4))

#define ldinfo_textorg(ldinfo, wordsize) \
 ((CORE_ADDR) extract_unsigned_integer ((ldinfo) + 2 * (wordsize), (wordsize)))

#define ldinfo_textsize(ldinfo, wordsize) \
 ((CORE_ADDR) extract_unsigned_integer ((ldinfo) + 3 * (wordsize), (wordsize)))

#define ldinfo_dataorg(ldinfo, wordsize) \
 ((CORE_ADDR) extract_unsigned_integer ((ldinfo) + 4 * (wordsize), (wordsize)))

#define ldinfo_datasize(ldinfo, wordsize) \
 ((CORE_ADDR) extract_unsigned_integer ((ldinfo) + 5 * (wordsize), (wordsize)))

#define ldinfo_filename(ldinfo, wordsize) \
 ((ldinfo) + 6 * (wordsize))

#define ldinfo_membername(ldinfo, wordsize) \
 (ldinfo_filename ((ldinfo), (wordsize)) \
  + strlen (ldinfo_filename ((ldinfo), (wordsize))) + 1)


struct lm_info
  {
    CORE_ADDR textorg;
    CORE_ADDR textsize;
    CORE_ADDR dataorg;
    CORE_ADDR datasize;
  };


/* Build a list of `struct so_list' objects describing the shared
   objects currently loaded in the inferior.  */
static struct so_list *
aix_current_sos (void)
{
  int wordsize = TARGET_PTR_BIT / 8;

  struct so_list *head = NULL;
  struct so_list **link_ptr = &head;

  gdb_byte *buf, *ldinfo;
  LONGEST len;

  /* Retrieve the LDINFO list from the target.  */
  len = target_read_alloc (ops, TARGET_OBJECT_LDINFO, NULL, &buf);
  if (len <= 0)
    return;

  /* Walk the LDINFO list, skipping the first entry (which is always the
     main executable), and allocate a so_list element for each entry.  */
  for (ldinfo = buf + ldinfo_next (buf, wordsize);
       ldinfo_next (ldinfo, wordsize);
       ldinfo += ldinfo_next (ldinfo, wordsize))
    {
      gdb_byte *filename = ldinfo_filename (ldinfo, wordsize);
      gdb_byte *membername = ldinfo_membername (ldinfo, wordsize);

      struct so_list *new = XZALLOC (struct so_list);
      new->lm_info = XZALLOC (struct lm_info);

      new->lm_info->textorg = ldinfo_textorg (ldinfo, wordsize);
      new->lm_info->textsize = ldinfo_textsize (ldinfo, wordsize);
      new->lm_info->dataorg = ldinfo_dataorg (ldinfo, wordsize);
      new->lm_info->datasize = ldinfo_datasize (ldinfo, wordsize);

      if (*membername)
	xsnprintf (new->so_name, SO_NAME_MAX_PATH_SIZE,
		   "%s (%s)", filename, membername);
      else
	xsnprintf (new->so_name, SO_NAME_MAX_PATH_SIZE, "%s", filename);

      strcpy (new->so_original_name, new->so_name);

      *link_ptr = new;
      link_ptr = &new->next;
    }

  xfree (buf);
  return head;
}

/* Clean up so_list entry.  */
static void
aix_free_so (struct so_list *so)
{
  xfree (so->lm_info->lm);
  xfree (so->lm_info);
}


/* Relocate section addresses.  */
static void
aix_relocate_section_addresses (struct so_list *so,
				struct section_table *sec)
{
  if (strcmp (sec->the_bfd_section->name, ".text") == 0)
    {
      sec->addr += so->lm_info->textorg;
      sec->endaddr += so->lm_info->textorg;
    }
  if (strcmp (sec->the_bfd_section->name, ".data") == 0)
    {
      sec->addr += so->lm_info->dataorg;
      sec->endaddr += so->lm_info->dataorg;
    }
  if (strcmp (sec->the_bfd_section->name, ".bss") == 0)
    {
      sec->addr += so->lm_info->dataorg;
      sec->endaddr += so->lm_info->dataorg;
    }
}


/* If no open symbol file, attempt to locate and open the main symbol
   file.  On SVR4 systems, this is the first link map entry.  If its
   name is here, we can open it.  Useful when attaching to a process
   without first loading its symbol file.  */
static int
aix_open_symbol_file_object (void *from_ttyp)
{
  /* FIXME: We could implement this.  */
  return 0;
}


/* Return 1 if PC lies in the dynamic symbol resolution code of the
   SVR4 run time loader.  */
static int
aix_in_dynsym_resolve_code (CORE_ADDR pc)
{
  /* FIXME: This is probably wrong.  */
  return in_plt_section (pc, NULL);
}


/* Additional shared library symbol handling.  Nothing to do.  */
static void
aix_special_symbol_handling (void)
{
}


/* Shared library startup.  */
static void
aix_solib_create_inferior_hook (void)
{
  gdb_byte *buf;
  LONGEST len;

  /* Retrieve the LDINFO list from the target.  */
  len = target_read_alloc (ops, TARGET_OBJECT_LDINFO, NULL, &ldinfo);
  if (len <= 0)
    return;

  /* Relocate main executable.  */
  if (ldinfo_next (ldinfo, wordsize))
    {
      CORE_ADDR textorg = ldinfo_textorg (ldinfo, wordsize);
      CORE_ADDR dataorg = ldinfo_textorg (ldinfo, wordsize);

      struct cleanup *old_chain;
      struct section_offsets *new_offsets;
      int i;

      new_offsets = xcalloc (symfile_objfile->num_sections,
			     sizeof (struct section_offsets));
      old_chain = make_cleanup (xfree, new_offsets);

      for (i = 0; i < objfile->num_sections; ++i)
	new_offsets->offsets[i] = ANOFFSET (objfile->section_offsets, i);

      new_offsets->offsets[SECT_OFF_TEXT (objfile)] += textorg;
      new_offsets->offsets[SECT_OFF_DATA (objfile)] += dataorg;
      new_offsets->offsets[SECT_OFF_BSS (objfile)] += dataorg;

      objfile_relocate (symfile_objfile, new_offsets);
      do_cleanups (old_chain);
    }

  xfree (ldinfo);
}

 
/* Shared library cleanup.  */
static void
aix_clear_solib (void)
{
}


static struct target_so_ops aix_so_ops;

extern initialize_file_ftype _initialize_aix_solib; /* -Wmissing-prototypes */

void
_initialize_aix_solib (void)
{
  aix_so_ops.relocate_section_addresses = aix_relocate_section_addresses;
  aix_so_ops.free_so = aix_free_so;
  aix_so_ops.clear_solib = aix_clear_solib;
  aix_so_ops.solib_create_inferior_hook = aix_solib_create_inferior_hook;
  aix_so_ops.special_symbol_handling = aix_special_symbol_handling;
  aix_so_ops.current_sos = aix_current_sos;
  aix_so_ops.open_symbol_file_object = aix_open_symbol_file_object;
  aix_so_ops.in_dynsym_resolve_code = aix_in_dynsym_resolve_code;

  /* FIXME: Don't do this here.  *_gdbarch_init() should set so_ops. */
  current_target_so_ops = &aix_so_ops;
}


-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: [commit/AIX] Fix error when loading core file

[Pedro Alves]

Ulrich Weigand wrote:
> Joel Brobecker wrote:
> 
>> I think the problem started when we introduced post_create_inferior.
>> This causes us to call the SOLIB_CREATE_INFERIOR_HOOK, which in our
>> case is defined as a call to xcoff_relocate_symtab. I haven't really
>> checked with older versions of GDB because rebuilding GDB on AIX is
>> mighty slow, but it very much looks like this function was not called
>> in the case of core files before. This function is assuming a live process,
>> not a core file. So what I did was do an early return when debugging
>> a core file.
> 
> Yes, if you look at the SOLIB_ADD definition:
> 
> #define SOLIB_ADD(a, b, c, d)   \
>   if (PIDGET (inferior_ptid))   \
>     /* Attach to process.  */  \
>     xcoff_relocate_symtab (PIDGET (inferior_ptid)); \
>   else          \
>     /* Core file.  */ \
>     xcoff_relocate_core (c);
> 
> it is clear that the _symtab version is intended to be called only
> in the case of live process.
> 
> It looks like something changed to get SOLIB_CREATE_INFERIOR_HOOK
> now invoked as well ...
> 
> 
>> What this made me realize, however, is that we should really be
>> converting the AIX port to using the target_so_ops. I'll try to do
>> that soon. In the meantime, the attached patch should be good enough.
> 
> Yes, I noticed that as well.  I had already started to do that, but
> got side-tracked by other stuff in the meantime.  One problem is that
> the ldinfo ptrace call that is required to get at the list of loaded
> shared libraries is really a native-only call.
> 
> I'd thought of defining a TARGET_OBJECT_LDINFO xfer_partial object
> that reflects the contents of the ldinfo, and use this in the
> implementation of a (platform-independent) solib-aix.c file.
> The rs6000 native target and the core file support would need to
> be extended to supply that object.
> 

If AIX needs to use native calls to get at the shared libraries list,
perhaps you could also look if the solib-target.c Daniel is pushing
for remote dll support, and see if it would be a good fit for AIX too.
As a quick look it seems so.  You would move aix_current_sos
to the target_ops, and perhaps needs a few other tweaks 
(aix_in_dynsym_resolve_code, and aix_solib_create_inferior_hook).
Although he presented it as remote support, it also makes sense
for native win32 debugging, so it may also make sense as native
AIX debugging.

You would need these applied:
http://sourceware.org/ml/gdb-patches/2007-05/msg00140.html
http://sourceware.org/ml/gdb-patches/2007-05/msg00145.html

Cheers,
Pedro Alves

Re: [commit/AIX] Fix error when loading core file

[Pedro Alves]

Pedro Alves wrote:
> Ulrich Weigand wrote:
>>
>> I'd thought of defining a TARGET_OBJECT_LDINFO xfer_partial object
>> that reflects the contents of the ldinfo, and use this in the
>> implementation of a (platform-independent) solib-aix.c file.
>> The rs6000 native target and the core file support would need to
>> be extended to supply that object.
>>
> 
> If AIX needs to use native calls to get at the shared libraries list,
> perhaps you could also look if the solib-target.c Daniel is pushing
> for remote dll support, and see if it would be a good fit for AIX too.
> As a quick look it seems so.  You would move aix_current_sos
> to the target_ops, and perhaps needs a few other tweaks 
> (aix_in_dynsym_resolve_code, and aix_solib_create_inferior_hook).
> Although he presented it as remote support, it also makes sense
> for native win32 debugging, so it may also make sense as native
> AIX debugging.
> 

Hummm, looking at it for another 30 seconds, made me realize
it isn't fit.  Although AIX tells us something loaded with
'wait (&status), (status == 0x57c)', it doesn't tell us
specifically *what* was loaded - we have to build a list
of current_sos every time.  Being so, case solib-target.c
gets more in the way than helps.  Your approach seems best.

Cheers,
Pedro Alves

Re: [commit/AIX] Fix error when loading core file

[Ulrich Weigand]

Pedro Alves wrote:
> Pedro Alves wrote:
> > Ulrich Weigand wrote:
> >>
> >> I'd thought of defining a TARGET_OBJECT_LDINFO xfer_partial object
> >> that reflects the contents of the ldinfo, and use this in the
> >> implementation of a (platform-independent) solib-aix.c file.
> >> The rs6000 native target and the core file support would need to
> >> be extended to supply that object.
> >>
> > 
> > If AIX needs to use native calls to get at the shared libraries list,
> > perhaps you could also look if the solib-target.c Daniel is pushing
> > for remote dll support, and see if it would be a good fit for AIX too.
> > As a quick look it seems so.  You would move aix_current_sos
> > to the target_ops, and perhaps needs a few other tweaks 
> > (aix_in_dynsym_resolve_code, and aix_solib_create_inferior_hook).
> > Although he presented it as remote support, it also makes sense
> > for native win32 debugging, so it may also make sense as native
> > AIX debugging.
> > 
> 
> Hummm, looking at it for another 30 seconds, made me realize
> it isn't fit.  Although AIX tells us something loaded with
> 'wait (&status), (status == 0x57c)', it doesn't tell us
> specifically *what* was loaded - we have to build a list
> of current_sos every time.  Being so, case solib-target.c
> gets more in the way than helps.  Your approach seems best.

Another reason why I like the TARGET_OBJECT_LDINFO approach
is that the ldinfo is also present in core files.  Using a
xfer_partial object allows to cleanly support both native
and core file debugging (and it can also be extended to
support remote debugging, if we ever want to do that on AIX).

In any case, thanks for looking at this!

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: [commit/AIX] Fix error when loading core file

[Daniel Jacobowitz]

On Mon, May 21, 2007 at 03:24:25PM +0200, Ulrich Weigand wrote:
> Another reason why I like the TARGET_OBJECT_LDINFO approach
> is that the ldinfo is also present in core files.  Using a
> xfer_partial object allows to cleanly support both native
> and core file debugging (and it can also be extended to
> support remote debugging, if we ever want to do that on AIX).

FWIW, that will work with solib-target too; I didn't use a target
object, but now that you've mentioned it I see that I could have.
I should have thought of that; the needs are very similar.

Of course, if I want to use a target object for this then I need to
change the qfDllInfo packet to a qXfer:libraries:read packet, which
means I can no longer test with my current SymbianOS target - that's
one reason why I've been avoiding cosmetic changes to the protocol.
But that's not a showstopper.

What do you think - would the centralized bookkeeping be helpful,
even though you don't have explicit load and unload reports?

-- 
Daniel Jacobowitz
CodeSourcery

Re: [commit/AIX] Fix error when loading core file

[Ulrich Weigand]

Daniel Jacobowitz wrote:
> On Mon, May 21, 2007 at 03:24:25PM +0200, Ulrich Weigand wrote:
> > Another reason why I like the TARGET_OBJECT_LDINFO approach
> > is that the ldinfo is also present in core files.  Using a
> > xfer_partial object allows to cleanly support both native
> > and core file debugging (and it can also be extended to
> > support remote debugging, if we ever want to do that on AIX).
> 
> FWIW, that will work with solib-target too; I didn't use a target
> object, but now that you've mentioned it I see that I could have.
> I should have thought of that; the needs are very similar.
> 
> Of course, if I want to use a target object for this then I need to
> change the qfDllInfo packet to a qXfer:libraries:read packet, which
> means I can no longer test with my current SymbianOS target - that's
> one reason why I've been avoiding cosmetic changes to the protocol.
> But that's not a showstopper.
> 
> What do you think - would the centralized bookkeeping be helpful,
> even though you don't have explicit load and unload reports?

Hmmm, I'm not sure how this would work for core files.  It looks like
solib-target would work only for targets that provide
to_get_shared_libraries -- are you suggesting to implement that for
the core file target?  I guess that would be a gdbarch callback to
implement the AIX-specific handling?

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: [commit/AIX] Fix error when loading core file

[Daniel Jacobowitz]

On Mon, May 28, 2007 at 10:00:30PM +0200, Ulrich Weigand wrote:
> Hmmm, I'm not sure how this would work for core files.  It looks like
> solib-target would work only for targets that provide
> to_get_shared_libraries -- are you suggesting to implement that for
> the core file target?  I guess that would be a gdbarch callback to
> implement the AIX-specific handling?

Right - that's exactly what I meant.  Except that I'm thinking now
that I made a mistake; I could have added a target object instead,
and then we could use a gdbarch method to implement that target object
based on a core file.  That's why I haven't followed up on the patch
yet; I'm going to try re-working it when I get back from vacation.

As to what the contents of the target object should be, I'm not sure.
The easiest choice would be the same as the remote protocol format,
e.g. "Name:HEXSTR,TextSeg=ADDR;Name:HEXSTR,TextSeg=Addr".  The other
alternative would be XML in case we think any flexibility would be
needed.  The nice thing about that is it avoids having to hex-encode
the name; we can XML-escape it instead, which is easier in common
cases.  Now that we have a nicely simple XML parsing infrastructure I
like to take advantage of it.

  <list>
    <library name="libc.so.6" textseg="0x40000000"/>
  </list>

-- 
Daniel Jacobowitz
CodeSourcery

Re: [commit/AIX] Fix error when loading core file

[Ulrich Weigand]

Daniel Jacobowitz wrote:
> On Mon, May 28, 2007 at 10:00:30PM +0200, Ulrich Weigand wrote:
> > Hmmm, I'm not sure how this would work for core files.  It looks like
> > solib-target would work only for targets that provide
> > to_get_shared_libraries -- are you suggesting to implement that for
> > the core file target?  I guess that would be a gdbarch callback to
> > implement the AIX-specific handling?
> 
> Right - that's exactly what I meant.  Except that I'm thinking now
> that I made a mistake; I could have added a target object instead,
> and then we could use a gdbarch method to implement that target object
> based on a core file.  That's why I haven't followed up on the patch
> yet; I'm going to try re-working it when I get back from vacation.

Sounds good, I think this would indeed work for the AIX case as well.

> As to what the contents of the target object should be, I'm not sure.
> The easiest choice would be the same as the remote protocol format,
> e.g. "Name:HEXSTR,TextSeg=ADDR;Name:HEXSTR,TextSeg=Addr".  The other
> alternative would be XML in case we think any flexibility would be
> needed.  The nice thing about that is it avoids having to hex-encode
> the name; we can XML-escape it instead, which is easier in common
> cases.  Now that we have a nicely simple XML parsing infrastructure I
> like to take advantage of it.

Do we also have infrastructure to *generate* XML?  We have to create
those contents in GDB (at least for the core file and AIX native
target cases).

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: [commit/AIX] Fix error when loading core file

[Daniel Jacobowitz]

On Thu, May 31, 2007 at 11:07:50PM +0200, Ulrich Weigand wrote:
> Do we also have infrastructure to *generate* XML?  We have to create
> those contents in GDB (at least for the core file and AIX native
> target cases).

Right.  We don't yet, but so far I've not had a problem; generating
XML is usually very simple, unless you want to handle escaping of
special characters.  If we do want to we could add a couple of simple
helper functions for that.  I don't think it would be more than an
hour or two's work.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [commit/AIX] Fix error when loading core file

[Joel Brobecker]

Ulrich,

> I'll try to get back to doing this, but it'll be some time.  If
> you want to work at it earlier, that would certainly be welcome.

If you don't mind looking at this, then this is great. I just noticed
some issues with thread switching that I can have a look at - I'm much
more familiar with this part of the code than with LDINFO structures...

-- 
Joel

Re: [commit/AIX] Fix error when loading core file

[Joel Brobecker]

> > I'll try to get back to doing this, but it'll be some time.  If
> > you want to work at it earlier, that would certainly be welcome.
> 
> If you don't mind looking at this, then this is great. I just noticed
> some issues with thread switching that I can have a look at - I'm much
> more familiar with this part of the code than with LDINFO structures...

Actually, I just found that this was an issue with our ada-tasks module.
AdaCore's debugger has an ada-tasks module that provides support for
the "task" concept that we have in Ada. We haven't contributed this
code yet because it is desperately in need of a rewrite. It is serving
very well, but the coding is not up to the GDB standards :-(.

Anyway, I am kept busy with stuff out of work (tennis officiating)
so I won't probably have a chance to have a look at this soon.
However, I will remember to send a note if I do have a chance
to work on this before you do.

-- 
Joel