This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Read corrrect auxiliary entry in AIX.
- From: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- To: sangamesh dot swamy at in dot ibm dot com (Sangamesh Mallayya)
- Cc: gdb-patches at sourceware dot org, Ulrich dot Weigand at de dot ibm dot com (Ulrich Weigand)
- Date: Tue, 22 Nov 2016 19:08:20 +0100 (CET)
- Subject: Re: [PATCH] Read corrrect auxiliary entry in AIX.
- Authentication-results: sourceware.org; auth=none
Sangamesh Mallayya wrote:
> Thanks for review and sorry for the long delay in responding to your
> comments.
No problem, thanks for the details, which seem to confirm what I had
been assuming.
> I checked the dbx behaviour in case of C_WEAKEXT.
> It seems to be handling C_WEAKEXT symbols too.
> So i think we might need to think of handling C_WEAKEXT too.
> But one question comes to mind is, why this case wasn't consider at the
>first place itself.
Well, I wouldn't be surprised if this code in GDB was older than support
for weak symbols in COFF, and was never updated when those were added ...
> > - Given the check above, can it *ever* happen that this check is false
> > and we still reach the LD/PR case? If so, we'd still have the problem
> > that the record is the wrong one and doesn't actually contain a size,
> > right? But if not, shouldn't we just have the function_entry_point
> > handling in one place and avoid the goto?
> >
> > - If there is just one place, should it be where you added the check
> > above, or rather in the LD/PR switch case?
> >
> > - Finally, given the check added above, can it still ever happen that
> > the original ISFCN check after the if C_EXT block is true? If so,
> > are we sure that the symbol will always have a function size in the
> > first aux entry? (I understand that if a symbol has just one aux
> > entry, it must be a csect one which doesn't have the function size.)
> > If not, this block should be removed as well.
> >
>
> Thanks for catching this.
>
> With current modification looks like we mayn't come to the original ISFCN
> check, as we aren't restricted on only one auxiliary entry
> and ISFCN check result to true for the functions with two auxiliary entry.
>
> Yes. As mentioned below the order of auxiliary entry is important and for
> functions first auxiliary entry is having the size information.
>
> Let me know your view.
So then I would suggest to restructure the logic along those lines:
if (cs->c_sclass == C_EXT || cs->c_sclass == C_HIDEXT
|| cs->c_sclass == C_WEAKEXT)
{
if (cs->c_naux > 1 && ISFCN (cs->c_type))
{
/* A function entry point. */
fcn_start_addr = cs->c_value;
/* Save the function header info, which will be used
when `.bf' is seen. */
fcn_cs_saved = *cs;
/* Read in main aux header to get the function size. */
bfd_coff_swap_aux_in (abfd, raw_auxptr, cs->c_type,
cs->c_sclass, 0, cs->c_naux,
&fcn_aux_saved);
continue;
}
/* Otherwise, read the CSECT aux header, which is always
the last one by convention. */
bfd_coff_swap_aux_in (abfd,
(raw_auxptr
+ (coff_data (abfd)->local_symesz
* (cs->c_naux - 1)),
cs->c_type, cs->c_sclass,
cs->c_naux - 1, cs->c_naux,
&main_aux);
switch (CSECT_SMTYP (&main_aux))
.... same code as currently, but remove the handling of LD/PR ...
}
... remove the if (ISFCN ...) block ...
Does this make sense to you?
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
Ulrich.Weigand@de.ibm.com