* Fix powerpc64-linux inferior function calls
@ 2005-09-28 7:34 Alan Modra
2005-10-02 22:31 ` Daniel Jacobowitz
0 siblings, 1 reply; 12+ messages in thread
From: Alan Modra @ 2005-09-28 7:34 UTC (permalink / raw)
To: gdb-patches
This gives me a gdb that can make inferior calls on powerpc64-linux when
debugging code compiled by a gcc that doesn't provide dot-symbols.
ppc-sysv-tdep.c:convert_code_addr_to_desc_addr needs dot-symbols to find
the function descriptor corresponding to a given pc.
It's a band-aid really. I think the proper fix is to not convert
function pointers to function code addresses in gdb's expression
evaluator, which would keep the pointer to the descriptor. This of
course would mean that gdb's breakpoint and similar code expecting that
function symbols point to code would need adjusting. One benefit would
be that "p *func" would print me the descriptor, which is what I'd
expect for powerpc64.
PR 2016
* elfread.c (elf_symtab_process): Split out from..
(elf_symtab_read): ..here.
(elf_symfile_read): Read both static and dynamic symbols before
processing. Call bfd_get_synthetic_symtab.
Index: gdb/elfread.c
===================================================================
RCS file: /cvs/src/src/gdb/elfread.c,v
retrieving revision 1.50
diff -u -p -r1.50 elfread.c
--- gdb/elfread.c 21 Feb 2005 11:00:44 -0000 1.50
+++ gdb/elfread.c 28 Sep 2005 06:59:55 -0000
@@ -124,7 +124,63 @@ record_minimal_symbol (char *name, CORE_
SYNOPSIS
- void elf_symtab_read (struct objfile *objfile, int dynamic)
+ long elf_symtab_read (struct objfile *objfile, int dynamic, asymbol ***syms)
+
+ DESCRIPTION
+
+ Given an objfile and a flag that specifies whether to read static or
+ dynamic symbols, read the raw BFD symbols. Return the number of symbols
+ and an array of pointers to the symbols.
+
+ */
+
+long
+elf_symtab_read (struct objfile *objfile, int dynamic, asymbol ***syms)
+{
+ long storage_needed;
+ asymbol **symbol_table = NULL;
+ long number_of_symbols = 0;
+
+ if (dynamic)
+ storage_needed = bfd_get_dynamic_symtab_upper_bound (objfile->obfd);
+ else
+ {
+ storage_needed = bfd_get_symtab_upper_bound (objfile->obfd);
+ if (storage_needed < 0)
+ error (_("Can't read symbols from %s: %s"),
+ bfd_get_filename (objfile->obfd),
+ bfd_errmsg (bfd_get_error ()));
+ }
+
+ if (storage_needed > 0)
+ {
+ symbol_table = (asymbol **) xmalloc (storage_needed);
+ if (dynamic)
+ number_of_symbols = bfd_canonicalize_dynamic_symtab (objfile->obfd,
+ symbol_table);
+ else
+ number_of_symbols = bfd_canonicalize_symtab (objfile->obfd,
+ symbol_table);
+ if (number_of_symbols < 0)
+ error (_("Can't read symbols from %s: %s"),
+ bfd_get_filename (objfile->obfd),
+ bfd_errmsg (bfd_get_error ()));
+ }
+
+ *syms = symbol_table;
+ return number_of_symbols;
+}
+
+/*
+
+ LOCAL FUNCTION
+
+ elf_symtab_process -- process the symbol table of an ELF file
+
+ SYNOPSIS
+
+ void elf_symtab_process (struct objfile *objfile, int dynamic
+ long number_of_symbols, asymbol **symbol_table)
DESCRIPTION
@@ -140,15 +196,12 @@ record_minimal_symbol (char *name, CORE_
*/
-static void
-elf_symtab_read (struct objfile *objfile, int dynamic)
+void
+elf_symtab_process (struct objfile *objfile, int dynamic,
+ long number_of_symbols, asymbol **symbol_table)
{
- long storage_needed;
asymbol *sym;
- asymbol **symbol_table;
- long number_of_symbols;
long i;
- struct cleanup *back_to;
CORE_ADDR symaddr;
CORE_ADDR offset;
enum minimal_symbol_type ms_type;
@@ -165,292 +218,262 @@ elf_symtab_read (struct objfile *objfile
struct dbx_symfile_info *dbx = objfile->deprecated_sym_stab_info;
int stripped = (bfd_get_symcount (objfile->obfd) == 0);
- if (dynamic)
+ for (i = 0; i < number_of_symbols; i++)
{
- storage_needed = bfd_get_dynamic_symtab_upper_bound (objfile->obfd);
+ sym = symbol_table[i];
+ if (sym->name == NULL || *sym->name == '\0')
+ {
+ /* Skip names that don't exist (shouldn't happen), or names
+ that are null strings (may happen). */
+ continue;
+ }
- /* Nothing to be done if there is no dynamic symtab. */
- if (storage_needed < 0)
- return;
- }
- else
- {
- storage_needed = bfd_get_symtab_upper_bound (objfile->obfd);
- if (storage_needed < 0)
- error (_("Can't read symbols from %s: %s"), bfd_get_filename (objfile->obfd),
- bfd_errmsg (bfd_get_error ()));
- }
- if (storage_needed > 0)
- {
- symbol_table = (asymbol **) xmalloc (storage_needed);
- back_to = make_cleanup (xfree, symbol_table);
- if (dynamic)
- number_of_symbols = bfd_canonicalize_dynamic_symtab (objfile->obfd,
- symbol_table);
- else
- number_of_symbols = bfd_canonicalize_symtab (objfile->obfd, symbol_table);
- if (number_of_symbols < 0)
- error (_("Can't read symbols from %s: %s"), bfd_get_filename (objfile->obfd),
- bfd_errmsg (bfd_get_error ()));
+ offset = ANOFFSET (objfile->section_offsets, sym->section->index);
+ if (dynamic
+ && sym->section == &bfd_und_section
+ && (sym->flags & BSF_FUNCTION))
+ {
+ struct minimal_symbol *msym;
+
+ /* Symbol is a reference to a function defined in
+ a shared library.
+ If its value is non zero then it is usually the address
+ of the corresponding entry in the procedure linkage table,
+ plus the desired section offset.
+ If its value is zero then the dynamic linker has to resolve
+ the symbol. We are unable to find any meaningful address
+ for this symbol in the executable file, so we skip it. */
+ symaddr = sym->value;
+ if (symaddr == 0)
+ continue;
+ symaddr += offset;
+ msym = record_minimal_symbol
+ ((char *) sym->name, symaddr,
+ mst_solib_trampoline, sym->section, objfile);
+#ifdef SOFUN_ADDRESS_MAYBE_MISSING
+ if (msym != NULL)
+ msym->filename = filesymname;
+#endif
+ continue;
+ }
- for (i = 0; i < number_of_symbols; i++)
+ /* If it is a nonstripped executable, do not enter dynamic
+ symbols, as the dynamic symbol table is usually a subset
+ of the main symbol table. */
+ if (dynamic && !stripped)
+ continue;
+ if (sym->flags & BSF_FILE)
{
- sym = symbol_table[i];
- if (sym->name == NULL || *sym->name == '\0')
+ /* STT_FILE debugging symbol that helps stabs-in-elf debugging.
+ Chain any old one onto the objfile; remember new sym. */
+ if (sectinfo != NULL)
{
- /* Skip names that don't exist (shouldn't happen), or names
- that are null strings (may happen). */
- continue;
+ sectinfo->next = dbx->stab_section_info;
+ dbx->stab_section_info = sectinfo;
+ sectinfo = NULL;
}
+ filesym = sym;
+#ifdef SOFUN_ADDRESS_MAYBE_MISSING
+ filesymname =
+ obsavestring ((char *) filesym->name, strlen (filesym->name),
+ &objfile->objfile_obstack);
+#endif
+ }
+ else if (sym->flags & BSF_SECTION_SYM)
+ continue;
+ else if (sym->flags & (BSF_GLOBAL | BSF_LOCAL | BSF_WEAK))
+ {
+ struct minimal_symbol *msym;
- offset = ANOFFSET (objfile->section_offsets, sym->section->index);
- if (dynamic
- && sym->section == &bfd_und_section
- && (sym->flags & BSF_FUNCTION))
+ /* Select global/local/weak symbols. Note that bfd puts abs
+ symbols in their own section, so all symbols we are
+ interested in will have a section. */
+ /* Bfd symbols are section relative. */
+ symaddr = sym->value + sym->section->vma;
+ /* Relocate all non-absolute symbols by the section offset. */
+ if (sym->section != &bfd_abs_section)
{
- struct minimal_symbol *msym;
-
- /* Symbol is a reference to a function defined in
- a shared library.
- If its value is non zero then it is usually the address
- of the corresponding entry in the procedure linkage table,
- plus the desired section offset.
- If its value is zero then the dynamic linker has to resolve
- the symbol. We are unable to find any meaningful address
- for this symbol in the executable file, so we skip it. */
- symaddr = sym->value;
- if (symaddr == 0)
- continue;
symaddr += offset;
- msym = record_minimal_symbol
- ((char *) sym->name, symaddr,
- mst_solib_trampoline, sym->section, objfile);
-#ifdef SOFUN_ADDRESS_MAYBE_MISSING
- if (msym != NULL)
- msym->filename = filesymname;
-#endif
- continue;
}
-
- /* If it is a nonstripped executable, do not enter dynamic
- symbols, as the dynamic symbol table is usually a subset
- of the main symbol table. */
- if (dynamic && !stripped)
- continue;
- if (sym->flags & BSF_FILE)
+ /* For non-absolute symbols, use the type of the section
+ they are relative to, to intuit text/data. Bfd provides
+ no way of figuring this out for absolute symbols. */
+ if (sym->section == &bfd_abs_section)
{
- /* STT_FILE debugging symbol that helps stabs-in-elf debugging.
- Chain any old one onto the objfile; remember new sym. */
- if (sectinfo != NULL)
+ /* This is a hack to get the minimal symbol type
+ right for Irix 5, which has absolute addresses
+ with special section indices for dynamic symbols. */
+ unsigned short shndx =
+ ((elf_symbol_type *) sym)->internal_elf_sym.st_shndx;
+
+ switch (shndx)
{
- sectinfo->next = dbx->stab_section_info;
- dbx->stab_section_info = sectinfo;
- sectinfo = NULL;
+ case SHN_MIPS_TEXT:
+ ms_type = mst_text;
+ break;
+ case SHN_MIPS_DATA:
+ ms_type = mst_data;
+ break;
+ case SHN_MIPS_ACOMMON:
+ ms_type = mst_bss;
+ break;
+ default:
+ ms_type = mst_abs;
}
- filesym = sym;
-#ifdef SOFUN_ADDRESS_MAYBE_MISSING
- filesymname =
- obsavestring ((char *) filesym->name, strlen (filesym->name),
- &objfile->objfile_obstack);
-#endif
- }
- else if (sym->flags & BSF_SECTION_SYM)
- continue;
- else if (sym->flags & (BSF_GLOBAL | BSF_LOCAL | BSF_WEAK))
- {
- struct minimal_symbol *msym;
- /* Select global/local/weak symbols. Note that bfd puts abs
- symbols in their own section, so all symbols we are
- interested in will have a section. */
- /* Bfd symbols are section relative. */
- symaddr = sym->value + sym->section->vma;
- /* Relocate all non-absolute symbols by the section offset. */
- if (sym->section != &bfd_abs_section)
+ /* If it is an Irix dynamic symbol, skip section name
+ symbols, relocate all others by section offset. */
+ if (ms_type != mst_abs)
{
+ if (sym->name[0] == '.')
+ continue;
symaddr += offset;
}
- /* For non-absolute symbols, use the type of the section
- they are relative to, to intuit text/data. Bfd provides
- no way of figuring this out for absolute symbols. */
- if (sym->section == &bfd_abs_section)
+ }
+ else if (sym->section->flags & SEC_CODE)
+ {
+ if (sym->flags & BSF_GLOBAL)
{
- /* This is a hack to get the minimal symbol type
- right for Irix 5, which has absolute addresses
- with special section indices for dynamic symbols. */
- unsigned short shndx =
- ((elf_symbol_type *) sym)->internal_elf_sym.st_shndx;
-
- switch (shndx)
- {
- case SHN_MIPS_TEXT:
- ms_type = mst_text;
- break;
- case SHN_MIPS_DATA:
- ms_type = mst_data;
- break;
- case SHN_MIPS_ACOMMON:
- ms_type = mst_bss;
- break;
- default:
- ms_type = mst_abs;
- }
-
- /* If it is an Irix dynamic symbol, skip section name
- symbols, relocate all others by section offset. */
- if (ms_type != mst_abs)
- {
- if (sym->name[0] == '.')
- continue;
- symaddr += offset;
- }
+ ms_type = mst_text;
}
- else if (sym->section->flags & SEC_CODE)
+ else if ((sym->name[0] == '.' && sym->name[1] == 'L')
+ || ((sym->flags & BSF_LOCAL)
+ && sym->name[0] == '$'
+ && sym->name[1] == 'L'))
+ /* Looks like a compiler-generated label. Skip
+ it. The assembler should be skipping these (to
+ keep executables small), but apparently with
+ gcc on the (deleted) delta m88k SVR4, it loses.
+ So to have us check too should be harmless (but
+ I encourage people to fix this in the assembler
+ instead of adding checks here). */
+ continue;
+ else
{
- if (sym->flags & BSF_GLOBAL)
+ ms_type = mst_file_text;
+ }
+ }
+ else if (sym->section->flags & SEC_ALLOC)
+ {
+ if (sym->flags & (BSF_GLOBAL | BSF_WEAK))
+ {
+ if (sym->section->flags & SEC_LOAD)
{
- ms_type = mst_text;
+ ms_type = mst_data;
}
- else if ((sym->name[0] == '.' && sym->name[1] == 'L')
- || ((sym->flags & BSF_LOCAL)
- && sym->name[0] == '$'
- && sym->name[1] == 'L'))
- /* Looks like a compiler-generated label. Skip
- it. The assembler should be skipping these (to
- keep executables small), but apparently with
- gcc on the (deleted) delta m88k SVR4, it loses.
- So to have us check too should be harmless (but
- I encourage people to fix this in the assembler
- instead of adding checks here). */
- continue;
else
{
- ms_type = mst_file_text;
+ ms_type = mst_bss;
}
}
- else if (sym->section->flags & SEC_ALLOC)
+ else if (sym->flags & BSF_LOCAL)
{
- if (sym->flags & (BSF_GLOBAL | BSF_WEAK))
- {
- if (sym->section->flags & SEC_LOAD)
- {
- ms_type = mst_data;
- }
- else
- {
- ms_type = mst_bss;
- }
- }
- else if (sym->flags & BSF_LOCAL)
+ /* Named Local variable in a Data section.
+ Check its name for stabs-in-elf. */
+ int special_local_sect;
+ if (strcmp ("Bbss.bss", sym->name) == 0)
+ special_local_sect = SECT_OFF_BSS (objfile);
+ else if (strcmp ("Ddata.data", sym->name) == 0)
+ special_local_sect = SECT_OFF_DATA (objfile);
+ else if (strcmp ("Drodata.rodata", sym->name) == 0)
+ special_local_sect = SECT_OFF_RODATA (objfile);
+ else
+ special_local_sect = -1;
+ if (special_local_sect >= 0)
{
- /* Named Local variable in a Data section.
- Check its name for stabs-in-elf. */
- int special_local_sect;
- if (strcmp ("Bbss.bss", sym->name) == 0)
- special_local_sect = SECT_OFF_BSS (objfile);
- else if (strcmp ("Ddata.data", sym->name) == 0)
- special_local_sect = SECT_OFF_DATA (objfile);
- else if (strcmp ("Drodata.rodata", sym->name) == 0)
- special_local_sect = SECT_OFF_RODATA (objfile);
- else
- special_local_sect = -1;
- if (special_local_sect >= 0)
+ /* Found a special local symbol. Allocate a
+ sectinfo, if needed, and fill it in. */
+ if (sectinfo == NULL)
{
- /* Found a special local symbol. Allocate a
- sectinfo, if needed, and fill it in. */
- if (sectinfo == NULL)
- {
- int max_index;
- size_t size;
+ int max_index;
+ size_t size;
- max_index
- = max (SECT_OFF_BSS (objfile),
- max (SECT_OFF_DATA (objfile),
- SECT_OFF_RODATA (objfile)));
-
- /* max_index is the largest index we'll
- use into this array, so we must
- allocate max_index+1 elements for it.
- However, 'struct stab_section_info'
- already includes one element, so we
- need to allocate max_index aadditional
- elements. */
- size = (sizeof (struct stab_section_info)
- + (sizeof (CORE_ADDR)
- * max_index));
- sectinfo = (struct stab_section_info *)
- xmalloc (size);
- memset (sectinfo, 0, size);
- sectinfo->num_sections = max_index;
- if (filesym == NULL)
- {
- complaint (&symfile_complaints,
- _("elf/stab section information %s without a preceding file symbol"),
- sym->name);
- }
- else
- {
- sectinfo->filename =
- (char *) filesym->name;
- }
+ max_index
+ = max (SECT_OFF_BSS (objfile),
+ max (SECT_OFF_DATA (objfile),
+ SECT_OFF_RODATA (objfile)));
+
+ /* max_index is the largest index we'll
+ use into this array, so we must
+ allocate max_index+1 elements for it.
+ However, 'struct stab_section_info'
+ already includes one element, so we
+ need to allocate max_index aadditional
+ elements. */
+ size = (sizeof (struct stab_section_info)
+ + (sizeof (CORE_ADDR)
+ * max_index));
+ sectinfo = (struct stab_section_info *)
+ xmalloc (size);
+ memset (sectinfo, 0, size);
+ sectinfo->num_sections = max_index;
+ if (filesym == NULL)
+ {
+ complaint (&symfile_complaints,
+ _("elf/stab section information %s without a preceding file symbol"),
+ sym->name);
+ }
+ else
+ {
+ sectinfo->filename =
+ (char *) filesym->name;
}
- if (sectinfo->sections[special_local_sect] != 0)
- complaint (&symfile_complaints,
- _("duplicated elf/stab section information for %s"),
- sectinfo->filename);
- /* BFD symbols are section relative. */
- symaddr = sym->value + sym->section->vma;
- /* Relocate non-absolute symbols by the
- section offset. */
- if (sym->section != &bfd_abs_section)
- symaddr += offset;
- sectinfo->sections[special_local_sect] = symaddr;
- /* The special local symbols don't go in the
- minimal symbol table, so ignore this one. */
- continue;
- }
- /* Not a special stabs-in-elf symbol, do regular
- symbol processing. */
- if (sym->section->flags & SEC_LOAD)
- {
- ms_type = mst_file_data;
- }
- else
- {
- ms_type = mst_file_bss;
}
+ if (sectinfo->sections[special_local_sect] != 0)
+ complaint (&symfile_complaints,
+ _("duplicated elf/stab section information for %s"),
+ sectinfo->filename);
+ /* BFD symbols are section relative. */
+ symaddr = sym->value + sym->section->vma;
+ /* Relocate non-absolute symbols by the
+ section offset. */
+ if (sym->section != &bfd_abs_section)
+ symaddr += offset;
+ sectinfo->sections[special_local_sect] = symaddr;
+ /* The special local symbols don't go in the
+ minimal symbol table, so ignore this one. */
+ continue;
+ }
+ /* Not a special stabs-in-elf symbol, do regular
+ symbol processing. */
+ if (sym->section->flags & SEC_LOAD)
+ {
+ ms_type = mst_file_data;
}
else
{
- ms_type = mst_unknown;
+ ms_type = mst_file_bss;
}
}
else
{
- /* FIXME: Solaris2 shared libraries include lots of
- odd "absolute" and "undefined" symbols, that play
- hob with actions like finding what function the PC
- is in. Ignore them if they aren't text, data, or bss. */
- /* ms_type = mst_unknown; */
- continue; /* Skip this symbol. */
+ ms_type = mst_unknown;
}
- msym = record_minimal_symbol
- ((char *) sym->name, symaddr,
- ms_type, sym->section, objfile);
- if (msym)
- {
- /* Pass symbol size field in via BFD. FIXME!!! */
- unsigned long size = ((elf_symbol_type *) sym)->internal_elf_sym.st_size;
- MSYMBOL_SIZE(msym) = size;
- }
+ }
+ else
+ {
+ /* FIXME: Solaris2 shared libraries include lots of
+ odd "absolute" and "undefined" symbols, that play
+ hob with actions like finding what function the PC
+ is in. Ignore them if they aren't text, data, or bss. */
+ /* ms_type = mst_unknown; */
+ continue; /* Skip this symbol. */
+ }
+ msym = record_minimal_symbol
+ ((char *) sym->name, symaddr,
+ ms_type, sym->section, objfile);
+ if (msym)
+ {
+ /* Pass symbol size field in via BFD. FIXME!!! */
+ unsigned long size = ((elf_symbol_type *) sym)->internal_elf_sym.st_size;
+ MSYMBOL_SIZE(msym) = size;
+ }
#ifdef SOFUN_ADDRESS_MAYBE_MISSING
- if (msym != NULL)
- msym->filename = filesymname;
+ if (msym != NULL)
+ msym->filename = filesymname;
#endif
- ELF_MAKE_MSYMBOL_SPECIAL (sym, msym);
- }
+ ELF_MAKE_MSYMBOL_SPECIAL (sym, msym);
}
- do_cleanups (back_to);
}
}
@@ -493,6 +516,12 @@ elf_symfile_read (struct objfile *objfil
struct elfinfo ei;
struct cleanup *back_to;
CORE_ADDR offset;
+ asymbol **static_syms;
+ asymbol **dyn_syms;
+ asymbol *synthsyms;
+ long num_static_syms;
+ long num_dyn_syms;
+ long synth_count;
init_minimal_symbol_collection ();
back_to = make_cleanup_discard_minimal_symbols ();
@@ -509,11 +538,42 @@ elf_symfile_read (struct objfile *objfil
chain of info into the dbx_symfile_info in objfile->deprecated_sym_stab_info,
which can later be used by elfstab_offset_sections. */
- elf_symtab_read (objfile, 0);
+ num_static_syms = elf_symtab_read (objfile, 0, &static_syms);
+ make_cleanup (xfree, static_syms);
/* Add the dynamic symbols. */
- elf_symtab_read (objfile, 1);
+ num_dyn_syms = elf_symtab_read (objfile, 1, &dyn_syms);
+ make_cleanup (xfree, dyn_syms);
+
+ /* Also, for the sake of powerpc64-linux, regenerate dot-symbols.
+ On other targets, this introduces syms marking PLT entries. */
+
+ synth_count = bfd_get_synthetic_symtab (objfile->obfd,
+ num_static_syms, static_syms,
+ num_dyn_syms, dyn_syms,
+ &synthsyms);
+ if (synth_count > 0)
+ {
+ asymbol **symp;
+ void *new_syms;
+ long i;
+
+ new_syms = xmalloc ((num_static_syms + synth_count + 1)
+ * sizeof (*symp));
+ symp = new_syms;
+ memcpy (symp, static_syms, num_static_syms * sizeof (*symp));
+ symp += num_static_syms;
+ for (i = 0; i < synth_count; i++)
+ *symp++ = synthsyms + i;
+ *symp = 0;
+ static_syms = new_syms;
+ num_static_syms += synth_count;
+ make_cleanup (xfree, static_syms);
+ }
+
+ elf_symtab_process (objfile, 0, num_static_syms, static_syms);
+ elf_symtab_process (objfile, 1, num_dyn_syms, dyn_syms);
/* Install any minimal symbols that have been collected as the current
minimal symbols for this objfile. The debug readers below this point
--
Alan Modra
IBM OzLabs - Linux Technology Centre
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: Fix powerpc64-linux inferior function calls
2005-09-28 7:34 Fix powerpc64-linux inferior function calls Alan Modra
@ 2005-10-02 22:31 ` Daniel Jacobowitz
2005-10-02 23:22 ` Alan Modra
0 siblings, 1 reply; 12+ messages in thread
From: Daniel Jacobowitz @ 2005-10-02 22:31 UTC (permalink / raw)
To: Alan Modra; +Cc: gdb-patches
On Wed, Sep 28, 2005 at 05:03:45PM +0930, Alan Modra wrote:
> This gives me a gdb that can make inferior calls on powerpc64-linux when
> debugging code compiled by a gcc that doesn't provide dot-symbols.
> ppc-sysv-tdep.c:convert_code_addr_to_desc_addr needs dot-symbols to find
> the function descriptor corresponding to a given pc.
>
> It's a band-aid really. I think the proper fix is to not convert
> function pointers to function code addresses in gdb's expression
> evaluator, which would keep the pointer to the descriptor. This of
> course would mean that gdb's breakpoint and similar code expecting that
> function symbols point to code would need adjusting. One benefit would
> be that "p *func" would print me the descriptor, which is what I'd
> expect for powerpc64.
>
> PR 2016
> * elfread.c (elf_symtab_process): Split out from..
> (elf_symtab_read): ..here.
> (elf_symfile_read): Read both static and dynamic symbols before
> processing. Call bfd_get_synthetic_symtab.
Why do we need to read both before processing either? I'm thinking of
the patch I posted here:
http://sourceware.org/ml/gdb-patches/2005-06/msg00220.html
and pinged a few weeks ago.
--
Daniel Jacobowitz
CodeSourcery, LLC
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: Fix powerpc64-linux inferior function calls
2005-10-02 22:31 ` Daniel Jacobowitz
@ 2005-10-02 23:22 ` Alan Modra
2005-10-02 23:48 ` Daniel Jacobowitz
0 siblings, 1 reply; 12+ messages in thread
From: Alan Modra @ 2005-10-02 23:22 UTC (permalink / raw)
To: gdb-patches
On Sun, Oct 02, 2005 at 06:31:18PM -0400, Daniel Jacobowitz wrote:
> > (elf_symfile_read): Read both static and dynamic symbols before
> > processing. Call bfd_get_synthetic_symtab.
>
> Why do we need to read both before processing either?
The powerpc64 get_synthetic_symtab will use both dynamic and static
symbol tables. Handy when debugging stripped objects. So both symbols
tables need to be read before calling bfd_get_synthetic_symtab.
> I'm thinking of
> the patch I posted here:
> http://sourceware.org/ml/gdb-patches/2005-06/msg00220.html
> and pinged a few weeks ago.
Which I see you do in this patch too. I didn't know about your patch
when I wrote mine.. The order of processing doesn't matter at all.
It just fell out that way in my patch. Incidentally, why did you
need to fudge the synthetic syms?
+ /* Synthetic symbols are not, strictly speaking, either local
+ or global. But we can treat them as global symbols, since
+ they are effectively dynamic symbols. */
+ synth_symbol_table[i]->flags |= BSF_GLOBAL;
Seems like this should be done in bfd if necessary.
--
Alan Modra
IBM OzLabs - Linux Technology Centre
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Fix powerpc64-linux inferior function calls
2005-10-02 23:22 ` Alan Modra
@ 2005-10-02 23:48 ` Daniel Jacobowitz
2005-10-03 0:35 ` Alan Modra
0 siblings, 1 reply; 12+ messages in thread
From: Daniel Jacobowitz @ 2005-10-02 23:48 UTC (permalink / raw)
To: Alan Modra; +Cc: gdb-patches
On Mon, Oct 03, 2005 at 08:52:28AM +0930, Alan Modra wrote:
> > I'm thinking of
> > the patch I posted here:
> > http://sourceware.org/ml/gdb-patches/2005-06/msg00220.html
> > and pinged a few weeks ago.
>
> Which I see you do in this patch too. I didn't know about your patch
> when I wrote mine.. The order of processing doesn't matter at all.
> It just fell out that way in my patch. Incidentally, why did you
> need to fudge the synthetic syms?
>
> + /* Synthetic symbols are not, strictly speaking, either local
> + or global. But we can treat them as global symbols, since
> + they are effectively dynamic symbols. */
> + synth_symbol_table[i]->flags |= BSF_GLOBAL;
>
> Seems like this should be done in bfd if necessary.
I don't remember precisely... ah, here it is. See elf_symtab_read.
if (sym->flags & BSF_FILE)
...
else if (sym->flags & BSF_SECTION_SYM)
...
else if (sym->flags & (BSF_GLOBAL | BSF_LOCAL | BSF_WEAK))
They won't be recorded as symbols if they have none of these bits set.
Do you want to change BFD to always create them as BSF_GLOBAL?
--
Daniel Jacobowitz
CodeSourcery, LLC
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: Fix powerpc64-linux inferior function calls
2005-10-02 23:48 ` Daniel Jacobowitz
@ 2005-10-03 0:35 ` Alan Modra
2005-10-03 1:04 ` Daniel Jacobowitz
0 siblings, 1 reply; 12+ messages in thread
From: Alan Modra @ 2005-10-03 0:35 UTC (permalink / raw)
To: gdb-patches
On Sun, Oct 02, 2005 at 07:48:34PM -0400, Daniel Jacobowitz wrote:
> I don't remember precisely... ah, here it is. See elf_symtab_read.
>
> if (sym->flags & BSF_FILE)
> ...
> else if (sym->flags & BSF_SECTION_SYM)
> ...
> else if (sym->flags & (BSF_GLOBAL | BSF_LOCAL | BSF_WEAK))
>
> They won't be recorded as symbols if they have none of these bits set.
> Do you want to change BFD to always create them as BSF_GLOBAL?
I think the symbols are OK as is. _bfd_elf_get_synthetic_symtab has
*s = **p->sym_ptr_ptr;
s->section = plt;
s->value = addr - plt->vma;
s->name = names;
ie. flags will be set from the destination sym for synthetic plt syms,
making the synthetic sym BSF_GLOBAL or BSF_LOCAL. The ppc64 code does
similarly. So I think your gdb patch should simply leave the synthetic
sym flags unchanged.
--
Alan Modra
IBM OzLabs - Linux Technology Centre
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: Fix powerpc64-linux inferior function calls
2005-10-03 0:35 ` Alan Modra
@ 2005-10-03 1:04 ` Daniel Jacobowitz
2005-10-03 3:32 ` Alan Modra
0 siblings, 1 reply; 12+ messages in thread
From: Daniel Jacobowitz @ 2005-10-03 1:04 UTC (permalink / raw)
To: Alan Modra; +Cc: gdb-patches
On Mon, Oct 03, 2005 at 10:05:06AM +0930, Alan Modra wrote:
> On Sun, Oct 02, 2005 at 07:48:34PM -0400, Daniel Jacobowitz wrote:
> > I don't remember precisely... ah, here it is. See elf_symtab_read.
> >
> > if (sym->flags & BSF_FILE)
> > ...
> > else if (sym->flags & BSF_SECTION_SYM)
> > ...
> > else if (sym->flags & (BSF_GLOBAL | BSF_LOCAL | BSF_WEAK))
> >
> > They won't be recorded as symbols if they have none of these bits set.
> > Do you want to change BFD to always create them as BSF_GLOBAL?
>
> I think the symbols are OK as is. _bfd_elf_get_synthetic_symtab has
>
> *s = **p->sym_ptr_ptr;
> s->section = plt;
> s->value = addr - plt->vma;
> s->name = names;
>
> ie. flags will be set from the destination sym for synthetic plt syms,
> making the synthetic sym BSF_GLOBAL or BSF_LOCAL. The ppc64 code does
> similarly. So I think your gdb patch should simply leave the synthetic
> sym flags unchanged.
Well, I'm 100% positive that it didn't work without that. Has this
changed recently?
--
Daniel Jacobowitz
CodeSourcery, LLC
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Fix powerpc64-linux inferior function calls
2005-10-03 1:04 ` Daniel Jacobowitz
@ 2005-10-03 3:32 ` Alan Modra
2005-10-03 4:40 ` Daniel Jacobowitz
0 siblings, 1 reply; 12+ messages in thread
From: Alan Modra @ 2005-10-03 3:32 UTC (permalink / raw)
To: gdb-patches
On Sun, Oct 02, 2005 at 09:04:37PM -0400, Daniel Jacobowitz wrote:
> > I think the symbols are OK as is. _bfd_elf_get_synthetic_symtab has
> >
> > *s = **p->sym_ptr_ptr;
> > s->section = plt;
> > s->value = addr - plt->vma;
> > s->name = names;
> >
> > ie. flags will be set from the destination sym for synthetic plt syms,
> > making the synthetic sym BSF_GLOBAL or BSF_LOCAL. The ppc64 code does
> > similarly. So I think your gdb patch should simply leave the synthetic
> > sym flags unchanged.
>
> Well, I'm 100% positive that it didn't work without that. Has this
> changed recently?
No. I tested my patch on powerpc64 and it worked without fudging
flags.. Ah! You were looking at plt symbols no doubt, and they are
typically undefined. For some reason, BFD doesn't set BSF_GLOBAL for
undefined syms, so the corresponding plt symbols won't have BSF_GLOBAL
set. I'll fix this in _bfd_elf_get_synthetic_symtab.
--
Alan Modra
IBM OzLabs - Linux Technology Centre
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Fix powerpc64-linux inferior function calls
2005-10-03 3:32 ` Alan Modra
@ 2005-10-03 4:40 ` Daniel Jacobowitz
2005-10-03 8:20 ` Alan Modra
0 siblings, 1 reply; 12+ messages in thread
From: Daniel Jacobowitz @ 2005-10-03 4:40 UTC (permalink / raw)
To: Alan Modra; +Cc: gdb-patches
On Mon, Oct 03, 2005 at 01:02:23PM +0930, Alan Modra wrote:
> On Sun, Oct 02, 2005 at 09:04:37PM -0400, Daniel Jacobowitz wrote:
> > > I think the symbols are OK as is. _bfd_elf_get_synthetic_symtab has
> > >
> > > *s = **p->sym_ptr_ptr;
> > > s->section = plt;
> > > s->value = addr - plt->vma;
> > > s->name = names;
> > >
> > > ie. flags will be set from the destination sym for synthetic plt syms,
> > > making the synthetic sym BSF_GLOBAL or BSF_LOCAL. The ppc64 code does
> > > similarly. So I think your gdb patch should simply leave the synthetic
> > > sym flags unchanged.
> >
> > Well, I'm 100% positive that it didn't work without that. Has this
> > changed recently?
>
> No. I tested my patch on powerpc64 and it worked without fudging
> flags.. Ah! You were looking at plt symbols no doubt, and they are
> typically undefined. For some reason, BFD doesn't set BSF_GLOBAL for
> undefined syms, so the corresponding plt symbols won't have BSF_GLOBAL
> set. I'll fix this in _bfd_elf_get_synthetic_symtab.
Thanks! I've no strong preference between the patches (mine minus the
BSF_GLOBAL hack) now.
--
Daniel Jacobowitz
CodeSourcery, LLC
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Fix powerpc64-linux inferior function calls
2005-10-03 4:40 ` Daniel Jacobowitz
@ 2005-10-03 8:20 ` Alan Modra
2006-03-03 14:04 ` David Lecomber
0 siblings, 1 reply; 12+ messages in thread
From: Alan Modra @ 2005-10-03 8:20 UTC (permalink / raw)
To: gdb-patches
On Mon, Oct 03, 2005 at 12:40:41AM -0400, Daniel Jacobowitz wrote:
> Thanks! I've no strong preference between the patches (mine minus the
> BSF_GLOBAL hack) now.
I prefer yours.
--
Alan Modra
IBM OzLabs - Linux Technology Centre
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Fix powerpc64-linux inferior function calls
2005-10-03 8:20 ` Alan Modra
@ 2006-03-03 14:04 ` David Lecomber
2006-03-03 14:11 ` David Lecomber
2006-03-30 9:53 ` Daniel Jacobowitz
0 siblings, 2 replies; 12+ messages in thread
From: David Lecomber @ 2006-03-03 14:04 UTC (permalink / raw)
To: Alan Modra; +Cc: gdb-patches
Hi Alan, and all,
On Mon, 2005-10-03 at 17:49 +0930, Alan Modra wrote:
> On Mon, Oct 03, 2005 at 12:40:41AM -0400, Daniel Jacobowitz wrote:
> > Thanks! I've no strong preference between the patches (mine minus the
> > BSF_GLOBAL hack) now.
>
> I prefer yours.
This stuff still appears to be broken!
A tarball I have from mid-June 20050615 works fine, recent CVS does not
and certainly back in November 20051116 did not work.
Take a simple C code..
int main(){ }
Compile "gcc -m64 -g"
This GDB was configured as "powerpc64-unknown-linux-gnu"...Using host
libthread_db library "/lib64/tls/libthread_db.so.1".
(gdb) b main
Breakpoint 1 at 0x100004f0: file hello.c, line 4.
(gdb) r
Starting program: /tmp/david/gdb-6.3.50.20051116/a.out
Breakpoint 1, main () at hello.c:4
4 }
(gdb) p (((void* (*) (int)) &malloc) (sizeof(int)))
Program received signal SIGSEGV, Segmentation fault.
0x00000000000992e0 in ?? ()
The program being debugged was signaled while in a function called from
GDB.
GDB remains in the frame where the signal was received.
To change this behavior use "set unwindonsignal on"
Evaluation of the expression containing the function (at 0x992e0) will
be abandoned.
But back in June, life was far far sweeter:
(gdb) p (((void* (*) (int)) &malloc) (sizeof(int)))
$1 = (void *) 0x10011010
All that casting stuff seemed to make it work in those days. It
believes malloc to have size 4, being an unknown thing, so a bit of
fudgery was letting us get the 8 byte address and call that..
From some debugging of the new GDB, it looks like
ppp64_linux_convert_from_func_ptr_addr is returning something garbagey..
0x992e0..
Also, not sure what it's trying to tell me here (with latest CVS):
(gdb) p (void* (*) (int))(&malloc)
$7 = (void *(*)()) @0x80001ab870: 0x992e0
Yet..
(gdb) x /4 0x80001ab870
0x80001ab870 <malloc>: 0x00000080 0x000e52e0 0x00000080
0x001bd748
-- and I think the true entry point of malloc should be
0x00000080000e52e or near enough..
Any hints about this appreciated..
d.
--
David Lecomber <david@lecomber.net>
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: Fix powerpc64-linux inferior function calls
2006-03-03 14:04 ` David Lecomber
@ 2006-03-03 14:11 ` David Lecomber
2006-03-30 9:53 ` Daniel Jacobowitz
1 sibling, 0 replies; 12+ messages in thread
From: David Lecomber @ 2006-03-03 14:11 UTC (permalink / raw)
To: dan; +Cc: gdb-patches
[-- Attachment #1: Type: text/plain, Size: 2053 bytes --]
Hi Dan,
I think this one arrived with your mega-change in September. I've
binary searched it to the diffs you made on 2005-09-10:
2005-09-10 Daniel Jacobowitz <dan@codesourcery.com>
Ulrich Weigand <uweigand@de.ibm.com>
When debugging it, as I said before, I really didn't believe the output
from where ppp64_linux_convert_from_func_ptr_addr attempted to read from
the address of that function pointer.. (stack is after my .sig..) but
that is also the point at which my subject knowledge is exhausted.
--
David Lecomber <david@lecomber.net>
#0 xfer_memory (memaddr=549757565040, myaddr=0x1ffffffcd70 "", len=8,
write=0, attrib=0x0, target=0x104965c8)
at /tmp/david/gdb-6.3.50.20051116/gdb/exec.c:477
#1 0x0000000010172948 in default_xfer_partial (ops=0x104965c8,
object=TARGET_OBJECT_MEMORY, annex=0x0, readbuf=0x1ffffffcd70 "",
writebuf=0x0, offset=549757565040, len=8) at /tmp/david/gdb-6.3.50.200
51116/gdb/target.c:1321
#2 0x0000000010171758 in target_xfer_partial (ops=0x104965c8,
object=TARGET_OBJECT_MEMORY, annex=0x0, readbuf=0x1ffffffcd70,
writebuf=0x0, offset=549757565040, len=8)
at /tmp/david/gdb-6.3.50.2005111
6/gdb/target.c:863
#3 0x0000000010172a80 in target_read_partial (ops=0x104965c8,
object=TARGET_OBJECT_MEMORY, annex=0x0, buf=0x1ffffffcd70 "",
offset=549757565040, len=8)
at /tmp/david/gdb-6.3.50.20051116/gdb/target.c:
1351
#4 0x0000000010172bc4 in target_read (ops=0x104965c8,
object=TARGET_OBJECT_MEMORY, annex=0x0, buf=0x1ffffffcd70 "",
offset=549757565040, len=8)
at /tmp/david/gdb-6.3.50.20051116/gdb/target.c:1373
#5 0x0000000010172e00 in get_target_memory (ops=0x104965c8,
addr=549757565040, buf=0x1ffffffcd70 "", len=8)
at /tmp/david/gdb-6.3.50.20051116/gdb/target.c:1414
#6 0x0000000010172eb0 in get_target_memory_unsigned (ops=0x104965c8,
addr=549757565040, len=8)
at /tmp/david/gdb-6.3.50.20051116/gdb/target.c:1426
#7 0x0000000010078220 in ppc64_linux_convert_from_func_ptr_addr
(gdbarch=0x1052dfb0, addr=549757565040, targ=0x104965c8)
at /tmp/david/gdb-6.3.50.20051116/gdb/ppc-linux-tdep.c:801
[-- Attachment #2: Attached message - Re: Fix powerpc64-linux inferior function calls --]
[-- Type: message/rfc822, Size: 3169 bytes --]
From: David Lecomber <david@lecomber.net>
To: Alan Modra <amodra@bigpond.net.au>
Cc: gdb-patches@sources.redhat.com
Subject: Re: Fix powerpc64-linux inferior function calls
Date: Fri, 03 Mar 2006 11:23:47 +0000
Message-ID: <1141385020.14575.71.camel@localhost.localdomain>
Hi Alan, and all,
On Mon, 2005-10-03 at 17:49 +0930, Alan Modra wrote:
> On Mon, Oct 03, 2005 at 12:40:41AM -0400, Daniel Jacobowitz wrote:
> > Thanks! I've no strong preference between the patches (mine minus the
> > BSF_GLOBAL hack) now.
>
> I prefer yours.
This stuff still appears to be broken!
A tarball I have from mid-June 20050615 works fine, recent CVS does not
and certainly back in November 20051116 did not work.
Take a simple C code..
int main(){ }
Compile "gcc -m64 -g"
This GDB was configured as "powerpc64-unknown-linux-gnu"...Using host
libthread_db library "/lib64/tls/libthread_db.so.1".
(gdb) b main
Breakpoint 1 at 0x100004f0: file hello.c, line 4.
(gdb) r
Starting program: /tmp/david/gdb-6.3.50.20051116/a.out
Breakpoint 1, main () at hello.c:4
4 }
(gdb) p (((void* (*) (int)) &malloc) (sizeof(int)))
Program received signal SIGSEGV, Segmentation fault.
0x00000000000992e0 in ?? ()
The program being debugged was signaled while in a function called from
GDB.
GDB remains in the frame where the signal was received.
To change this behavior use "set unwindonsignal on"
Evaluation of the expression containing the function (at 0x992e0) will
be abandoned.
But back in June, life was far far sweeter:
(gdb) p (((void* (*) (int)) &malloc) (sizeof(int)))
$1 = (void *) 0x10011010
All that casting stuff seemed to make it work in those days. It
believes malloc to have size 4, being an unknown thing, so a bit of
fudgery was letting us get the 8 byte address and call that..
From some debugging of the new GDB, it looks like
ppp64_linux_convert_from_func_ptr_addr is returning something garbagey..
0x992e0..
Also, not sure what it's trying to tell me here (with latest CVS):
(gdb) p (void* (*) (int))(&malloc)
$7 = (void *(*)()) @0x80001ab870: 0x992e0
Yet..
(gdb) x /4 0x80001ab870
0x80001ab870 <malloc>: 0x00000080 0x000e52e0 0x00000080
0x001bd748
-- and I think the true entry point of malloc should be
0x00000080000e52e or near enough..
Any hints about this appreciated..
d.
--
David Lecomber <david@lecomber.net>
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: Fix powerpc64-linux inferior function calls
2006-03-03 14:04 ` David Lecomber
2006-03-03 14:11 ` David Lecomber
@ 2006-03-30 9:53 ` Daniel Jacobowitz
1 sibling, 0 replies; 12+ messages in thread
From: Daniel Jacobowitz @ 2006-03-30 9:53 UTC (permalink / raw)
To: David Lecomber; +Cc: Alan Modra, gdb-patches
On Fri, Mar 03, 2006 at 11:23:40AM +0000, David Lecomber wrote:
> This stuff still appears to be broken!
Really?
> Take a simple C code..
> int main(){ }
>
> Compile "gcc -m64 -g"
>
> This GDB was configured as "powerpc64-unknown-linux-gnu"...Using host
> libthread_db library "/lib64/tls/libthread_db.so.1".
> (gdb) b main
> Breakpoint 1 at 0x100004f0: file hello.c, line 4.
> (gdb) r
> Starting program: /tmp/david/gdb-6.3.50.20051116/a.out
> Breakpoint 1, main () at hello.c:4
> 4 }
> (gdb) p (((void* (*) (int)) &malloc) (sizeof(int)))
> Program received signal SIGSEGV, Segmentation fault.
> 0x00000000000992e0 in ?? ()
> The program being debugged was signaled while in a function called from
> GDB.
> GDB remains in the frame where the signal was received.
> To change this behavior use "set unwindonsignal on"
> Evaluation of the expression containing the function (at 0x992e0) will
> be abandoned.
[dan@belgarath obj]$ ./gdb/gdb g
GNU gdb 6.4.50.20060329-cvs
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "powerpc64-unknown-linux-gnu"...Using host libthread_db library "/lib64/tls/libthread_db.so.1".
(gdb) start
Breakpoint 1 at 0x100004c0: file g.c, line 1.
Starting program: /scratch/dan/obj/g
main () at g.c:1
1 int main(){ }
(gdb) p (((void* (*) (int)) &malloc) (sizeof(int)))
$1 = (void *) 0x10011010
(gdb) p (((void* (*) (int)) &malloc) (sizeof(int)))
$2 = (void *) 0x10011030
(gdb) p (((void* (*) (int)) &malloc) (sizeof(int)))
$3 = (void *) 0x10011050
Looks like it works to me. This is a relatively old powerpc64-linux
installation; it uses dot symbols. malloc references the opd entry
rather than the function. Things seem to work.
(gdb) x/2gx &malloc
0x80911ba760 <malloc>: 0x00000080910d0a48 0x00000080911cb718
> Also, not sure what it's trying to tell me here (with latest CVS):
> (gdb) p (void* (*) (int))(&malloc)
> $7 = (void *(*)()) @0x80001ab870: 0x992e0
(gdb) p (void* (*) (int))(&malloc)
$4 = (void *(*)()) @0x80911ba760: 0x80910d0a48 <.malloc>
Sorry, but I can't reproduce your problem on the only powerpc64-linux
system I have access to.
--
Daniel Jacobowitz
CodeSourcery
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2006-03-30 0:05 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-09-28 7:34 Fix powerpc64-linux inferior function calls Alan Modra
2005-10-02 22:31 ` Daniel Jacobowitz
2005-10-02 23:22 ` Alan Modra
2005-10-02 23:48 ` Daniel Jacobowitz
2005-10-03 0:35 ` Alan Modra
2005-10-03 1:04 ` Daniel Jacobowitz
2005-10-03 3:32 ` Alan Modra
2005-10-03 4:40 ` Daniel Jacobowitz
2005-10-03 8:20 ` Alan Modra
2006-03-03 14:04 ` David Lecomber
2006-03-03 14:11 ` David Lecomber
2006-03-30 9:53 ` Daniel Jacobowitz
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox