This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Read corrrect auxiliary entry in AIX.


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]