This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: read correct xcoff auxiliary entry & skip reading @fix entries.
- From: "Sangamesh Mallayya" <sangamesh dot swamy at in dot ibm dot com>
- To: GDB Patches <gdb-patches at sourceware dot org>, Ulrich Weigand <Ulrich dot Weigand at de dot ibm dot com>
- Cc: "David Edelsohn" <edelsohn at us dot ibm dot com>
- Date: Wed, 14 Jun 2017 11:27:58 +0530
- Subject: Re: read correct xcoff auxiliary entry & skip reading @fix entries.
- Authentication-results: sourceware.org; auth=none
- References: <CAGWvnykUJmRTgQM_6k3=8SMtJzA22UgookqGN9Y1Ve8vCk9a9w@mail.gmail.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