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]

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


Starting a new mail chain as it dated back to last month :-

This patch is for addressing the case when the debugee is compiled with
xlc -qfuncsect or gcc --ffunction-sections. It also changes the data type
of "fcn_start_address" from int to CORE_ADDR to make it large enough to
read XCOFF64 format.

The above mentioned compiler options basically splits a single source file
into several ".text" sections. Each function is assigned its own section.
In the case of xlc, we need to read the second aux entry of the xcoff
symbol
of ".text" type. The actual code only reads the first aux entry for a csect
which holds good for gcc but not xlc compiled with -qfuncsect.

A small example to show the difference between how xlc -qfuncsect defines
the
start of a .text section and how gcc does it :-

gcc :-

[176]   m   0x10000360     .text     1  unamex                    .main
[177]   a4  0x00000038       0    0     SD       PR    0    0

xlc :-

[86]    m   0x10000380     .text     2  unamex                    .main
[87]    a1           0         0    36       0       0
[88]    a4  0x00000024       0    0     SD       PR    0    0

where a1,a4 signify the auxiliary entries. As it can be seen in case of
xlc with -qfuncsect we need to read the 2nd aux entry. This is taken care
in this patch.

> Raunaq 12 wrote:
>
> >    unsigned int max_symnum;
> >    int just_started = 1;
> >    int depth = 0;
> > -  int fcn_start_addr = 0;
> > +  file_ptr fcn_start_addr = 0;
> Ulrich Weigand wrote:
>
> This seems to address only part of the problem.  This variable is
> initialized from cs->c_value, which itself is declared as "long".
> If that needs to hold a 64-bit value, shouldn't c_value itself
> be using "file_ptr"?  In theory we could build a cross-debugger
> hosted on a 32-bit platform to debug 64-bit AIX ...
>
> Also, several other places copy "c_value" contents into variables
> of type "int".  Don't those also need changing?

Ulrich, I changed the data type of fcn_start_addr to CORE_ADDR
as I noticed that other address related variables that derive their
value from cs->c_value also are of this type. In XCOFF64 format,
the section length uses 8 Bytes instead of 4. Therefore, 'long'
data type for cs->c_value suffices. Just the fcn_start_addr was of
a smaller size so I took care of that.

> > -  char *filestring = " _start_ ";   /* Name of the current file.  */
> > +  char *filestring = pst -> filename; /* Name of the current file.  */
>
> Isn't the code in the C_FILE switch case supposed to handle
> detecting the correct file name(s)?  Why doesn't that work
> for you?  Maybe that place also needs to be adapted to
> handle multiple aux entries?

Also, because the options -qfuncsect and --ffunction-sections create
seperate sections for each function, the symtabs of these sections
do not get updated with the correct filename and remain as "_start_".
This is also addressed in this patch in a better way than what I had
previously suggested.

---
ChangeLog-
		 * xcoffread.c (read_xcoff_symtab): Make fcn_start_addr
		 large enough to hold 64-bit address.
		 Make name of current file as pst->filename instead of _start_
		 if a csect has no filename associated with it.
		 Read correct auxiliary entry if the entries are more than
		 1 in case the dubugee is compiled with xlc -qfuncsect.
---
Any thoughts ?
Attaching the patch here.
(See attached file: gdb-7.6-xcoffread_symtab.patch)

Regards,
Raunaq

Attachment: gdb-7.6-xcoffread_symtab.patch
Description: Binary data


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