Toolchain/binutils-gdb
1
0
Fork 0
forked from Imagelibrary/binutils-gdb
Code Pull Requests Activity

* paread.c (pa_symtab_read): Put file-local symbols in minimal symbols.

Browse Source 
* hppa-tdep.c (frame_chain_valid): Check that our function has the
	same address as _start, not that it must be the same symbol.
This commit is contained in:
Jim Kingdon
1993-07-30 15:52:26 +00:00
parent ca33fca1f9
commit 247145e6f0
3 changed files with 29 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
gdb/ChangeLog
View File

@@ -12,6 +12,8 @@ Fri Jul 30 07:36:53 1993 Fred Fish (fnf@deneb.cygnus.com)
Fri Jul 30 08:58:01 1993 Jim Kingdon (kingdon@lioth.cygnus.com)
* paread.c (pa_symtab_read): Put file-local symbols in minimal symbols.
* hppa-tdep.c (frame_chain_valid): Check that our function has the
same address as _start, not that it must be the same symbol.
Fri Jul 30 00:18:40 1993 Fred Fish (fnf@deneb.cygnus.com)

17
gdb/hppa-tdep.c
View File

@@ -540,7 +540,8 @@ frame_chain_valid (chain, thisframe)
FRAME_ADDR chain;
FRAME thisframe;
{
struct minimal_symbol *msym;
struct minimal_symbol *msym_us;
struct minimal_symbol *msym_start;
struct unwind_table_entry *u;
if (!chain)
@@ -548,9 +549,17 @@ frame_chain_valid (chain, thisframe)
u = find_unwind_entry (thisframe->pc);
msym = lookup_minimal_symbol_by_pc (FRAME_SAVED_PC (thisframe));
if (msym
&& (strcmp (SYMBOL_NAME (msym), "_start") == 0))
/* We can't just check that the same of msym_us is "_start", because
someone idiotically decided that they were going to make a Ltext_end
symbol with the same address. This Ltext_end symbol is totally
indistinguishable (as nearly as I can tell) from the symbol for a function
which is (legitimately, since it is in the user's namespace)
named Ltext_end, so we can't just ignore it. */
msym_us = lookup_minimal_symbol_by_pc (FRAME_SAVED_PC (thisframe));
msym_start = lookup_minimal_symbol ("_start", NULL);
if (msym_us
&& msym_start
&& SYMBOL_VALUE_ADDRESS (msym_us) == SYMBOL_VALUE_ADDRESS (msym_start))
return 0;
if (u == NULL)

22
gdb/paread.c
View File

@@ -157,7 +157,10 @@ pa_symtab_read (abfd, addr, objfile)
}
break;
#if 0
/* SS_GLOBAL and SS_LOCAL are two names for the same thing (!). */
case SS_GLOBAL:
#endif
case SS_LOCAL:
switch (bufp->symbol_type)
{
@@ -167,19 +170,18 @@ pa_symtab_read (abfd, addr, objfile)
case ST_CODE:
symname = bufp->name.n_strx + stringtab;
ms_type = mst_file_text;
bufp->symbol_value &= ~0x3; /* clear out permission bits */
check_strange_names:
/* GAS leaves symbols with the prefixes "LS$", "LBB$",
and "LBE$" in .o files after assembling. And thus
they appear in the final executable. This can
cause problems if these special symbols have the
same value as real symbols. So ignore them. Is this
meant as a feature, or is it just a GAS bug? */
same value as real symbols. So ignore them. Also "LC$". */
if (*symname == 'L'
&& (symname[2] == '$' && symname[1] == 'S'
|| (symname[3] == '$' && symname[1] == 'B'
&& (symname[2] == 'B' || symname[2] == 'E'))))
&& (symname[2] == '$' || symname[3] == '$'))
continue;
ms_type = mst_file_text;
bufp->symbol_value &= ~0x3; /* clear out permission bits */
break;
case ST_PRI_PROG:
@@ -190,13 +192,17 @@ pa_symtab_read (abfd, addr, objfile)
ms_type = mst_file_text;
bufp->symbol_value &= ~0x3; /* clear out permission bits */
break;
case ST_DATA:
symname = bufp->name.n_strx + stringtab;
ms_type = mst_file_data;
break;
goto check_strange_names;
default:
continue;
}
break;
default:
continue;
}