Re: [PATCH] xcoff64 support, read correct aux entries in case of xlc, qfuncsect and ffunction-sections filename update.

["Ulrich Weigand" <uweigand at de dot ibm dot com>]

Raunaq 12 wrote:

> > However, I now have the reverse question: if we already (have to and can)
> > trust pst->filename, why do we even need the " _start_ " dummy string?
> > Is there any place where we *want* to see " _start_ "?
> 
> This was the question I asked myself too when I initially thought of
> hard-coding filesrtring to pst->filename directly.
> Going through the xcoffread.c code I see that no place really is looking
> for
> " _start_ ". Its just used as a default filename if no C_FILE entries are
> seen
> while calling read_xcoff_symtab.
> 
> My guess is that sometimes scan_xcoff_symtab creates psymtabs without
> assigning
> pst->filename as no C_FILE entries are seen. Is that a possibility ?
> If so, then the default _start_ value will be assigned to it.

I don't see how that is possible.  scan_xcoff_symtab can create a new
psymtab either in the C_FILE case, where it has a filename, or else
in the SD/PR C_EXT case, but only if there already was a prior psymtab,
and in then re-uses the same filename.


> The way the code has been designed, there are 2 ways to reach
> function_entry_point:
> 
> 1) There is a check for IFSCN
> 	-> if (ISFCN (cs->c_type) && cs->c_sclass != C_TPDEF)
>    which directly takes it to function_entry_point.
> 
> 2) The symbol type is read :-
> 
>            switch (CSECT_SMTYP (&main_aux))
>       	case XTY_SD:
> 		   ....
>             case XTY_LD:
> 
>               switch (CSECT_SCLAS (&main_aux))
>                 {
>                 case XMC_PR:
> 
> And this also takes us to function_entry_point.
> 
> If we just read the first aux entry, it reaches function_entry_point
> through the option 1. With the fsize already read.
> This is what was happening with my initail patch.
> 
> If we use the method you mentioned below, It will read the last aux
> entry, realize that it is a function, take the way I mentioned in (2)
> above, and then read the 1st aux entry for the function size.
> 
> In either case, the outcome is exactly the same and we are not losing
> any important info as the last aux entry for function start symbols
> just contain the symbol type and class and no other info.
> 
> Which way is better?

As you say, the existing code has two different ways to detect
functions.  I had been assuming this is necessary to capture
all potential cases.  E.g. that there could be a case where a
function is not marked ISFCN, but still has a LD/PR C_EXT
record.  (I don't know enough about the XCOFF format to know
if such cases can really occur.)

My suggested patch retains the ability to detect both of those
situations.  With your patch, if it indeed can happen that we
have a function that has a LD/PR C_EXT record but is *not*
marked as ISFCN, we would now miss it.


Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU/Linux compilers and toolchain
  Ulrich.Weigand@de.ibm.com