Re: read correct xcoff auxiliary entry & skip reading @fix entries.

["Sangamesh Mallayya" <sangamesh dot swamy at in dot ibm dot com>]

As david mentioned looks like dbx is ignoring @FIX entries.
Tried with one program and need to try some more examples.

And even in GDB code i see that most of the part it's has been tried to 
skip @FIX entries.
So, it looks like it makes more sense to skip the @FIX entries having to 
consider any issues which might occur.


from GDB code snippet

gdb/rs6000-tdep.c
=================

2268 /* Return whether handle_inferior_event() should proceed through code
2269    starting at PC in function NAME when stepping.
2270 
2271    The AIX -bbigtoc linker option generates functions @FIX0, @FIX1, 
etc. to
2272    handle memory references that are too distant to fit in 
instructions
2273    generated by the compiler.  For example, if 'foo' in the following
2274    instruction:
2275 
2276      lwz r9,foo(r2)
2277 
2278    is greater than 32767, the linker might replace the lwz with a 
branch to
2279    somewhere in @FIX1 that does the load in 2 instructions and then 
branches
2280    back to where execution should continue.
2281 
2282    GDB should silently step over @FIX code, just like AIX dbx does.
2283    Unfortunately, the linker uses the "b" instruction for the
2284    branches, meaning that the link register doesn't get set.
2285    Therefore, GDB's usual step_over_function () mechanism won't work.
2286 
2287    Instead, use the gdbarch_skip_trampoline_code and
2288    gdbarch_skip_trampoline_code hooks in handle_inferior_event() to 
skip past
2289    @FIX code.  */
2290 
2291 static int
2292 rs6000_in_solib_return_trampoline (struct gdbarch *gdbarch,
2293                                    CORE_ADDR pc, const char *name)
2294 {
2295   return name && startswith (name, "@FIX");
2296 }




xcoffread.c
===========


2339                     /* Activate the misc_func_recorded mechanism for
2340                        compiler- and linker-generated CSECTs like 
".strcmp"
2341                        and "@FIX1".  */
2342                     if (namestring && (namestring[0] == '.'
2343                                        || namestring[0] == '@'))
2344                       {
2345                         last_csect_name = namestring;
2346                         last_csect_val = symbol.n_value;
2347                         last_csect_sec = symbol.n_scnum;
2348                       }



2848                 /* We need only the minimal symbols for these
2849                    loader-generated definitions.  Keeping the global
2850                    symbols leads to "in psymbols but not in symbols"
2851                    errors.  */
2852                 if (startswith (namestring, "@FIX"))
2853                   continue;

Thanks,
-Sangamesh




From:   David Edelsohn <dje.gcc@gmail.com>
To:     Ulrich Weigand <Ulrich.Weigand@de.ibm.com>, Sangamesh 
Mallayya/India/IBM@IBMIN
Cc:     GDB Patches <gdb-patches@sourceware.org>
Date:   10/13/2016 07:57 AM
Subject:        Re: read correct xcoff auxiliary entry & skip reading @fix 
entries.



>>>>> Ulrich Weigand wrote:

> As a more substantiative comment, I'm wondering whether it really
> correct to just complely reject all @FIX symbols from consideration.
> I'm not really very familiar with the XCOFF format, but I do notice
> that there are several places in the rest of the code that appear to
> want to do something with @FIX symbols:

AIX did not have the equivalent of PPC64 Linux cmodel=medium/large
until recently. Prior to allowing the compiler to generate extra
instructions that the linker could elide, the AIX linker provided the
"bigtoc" linker option.

When "bigtoc" is enabled in the linker, the linker replaces the
instruction to load an address from the TOC with a jump to fixup code
that loads the address from another TOC table.  The names of the fixup
functions are @FIXn.

The AIX debugger, dbx, silently steps over those functions, but it's
not clear that GDB should be completely unaware of the symbols.  There
were some issues in the past with form that the AIX linker inserted
the symbols into the symbol table and GDB tried to work around that
based on the @FIXn symbol name.

Sometimes one wants the linker-generated symbols to be hidden when
debugging a program and sometimes one needs to be able to follow the
exact behavior of the program or shared object.

Thanks, David