Home » Language IDEs » C / C++ IDE (CDT) » CDT implementation question
| CDT implementation question [message #29271] |
Fri, 03 May 2002 15:54  |
Eclipse User |
|
|
|
Hi -
I have a question regarding the CDT implementation. If I understand
things correctly, a Part (GdbPart) represents an object file in
EPDC-speak. Each GdbPart mantains a list of methods associated with the
particular Part. Specifically, GdbPart mentains a list of MethodInfo
objects, which identify functions according to: name, full name, return
type, line num, and starting line num.
Given this list of attributes for each function, consider the case of
one object file compiled from multiple C source files. It is possible
for each of these C files to have separate static C functions of the
same name. How would the CDT be able to distinguish between such
functions? It seems like the MethodInfo class would require a field for
the associated source file, or am I confused?
Thanks in advance-
John
|
|
|
| Re: CDT implementation question [message #29998 is a reply to message #29271] |
Mon, 06 May 2002 13:22  |
| Eclipse User |
|
|
|
Hi John,
As you have stated, a Part represents an object file and each part
maintains a list of functions from that part. In GDBPicl, a part is only
associated with one source file. As a result, MethodInfo does not have a
field to store source file information.
I tried to create the scenario you described for AIX on Linux with gcc. I
could not create the scenario since I got an error message about function
redefinition when trying to compile my testcase. Regarding your case that
an object is created from multiple source files containing static
functions of the same name, don't you get an error during compile or link
step?
Assuming this is really possible, according to current GDBPicl disign, you
will probably get two differnt parts for the static functions. In
GDBPicl, a part is only created if its associated source file is part of
the call stack.
As you step into a function, GDBPicl gets the function's associated
filename using "info stack". If GDBPicl does not already have a part of
that source file, it will create the part based on the source filename.
As you step into the other static function, you will get a different
filename for that function. Again, if GDBPicl does not already have that
part, it will create it and associate the static function with the newly
created part.
Please note that although GDBPicl has some methods to query functions
information, those methods are not currently used. Functions information
is not maintained by GDBPicl at the moment and it will function properly
without function information. Function information was only queried to
construct a module view, which list all the modules, parts, source files
and functions in a tree structure. This view is currently disabled
because it is very expensive to query for function information from GDB.
Samantha
John Rose wrote:
> Hi -
> I have a question regarding the CDT implementation. If I understand
> things correctly, a Part (GdbPart) represents an object file in
> EPDC-speak. Each GdbPart mantains a list of methods associated with the
> particular Part. Specifically, GdbPart mentains a list of MethodInfo
> objects, which identify functions according to: name, full name, return
> type, line num, and starting line num.
> Given this list of attributes for each function, consider the case of
> one object file compiled from multiple C source files. It is possible
> for each of these C files to have separate static C functions of the
> same name. How would the CDT be able to distinguish between such
> functions? It seems like the MethodInfo class would require a field for
> the associated source file, or am I confused?
> Thanks in advance-
> John
|
|
|
| Re: CDT implementation question [message #30010 is a reply to message #29998] |
Mon, 06 May 2002 14:55 |
| Eclipse User |
|
|
|
Originally posted by: johnrose.nospam.com
Samantha-
Thanks for the reply. My test case consists of one object file
compiled from
two source files. The source files file1.c and file2.c both contain a
static
function func1(), each with a different definition. Neither gcc nor xlc
complains when compiling such a case on AIX.
In any case, this should not pose a problem since a Part is created to
represent one source file.
Thanks for the explanation!
John
Samantha Chan wrote:
>
> Hi John,
>
> As you have stated, a Part represents an object file and each part
> maintains a list of functions from that part. In GDBPicl, a part is only
> associated with one source file. As a result, MethodInfo does not have a
> field to store source file information.
>
> I tried to create the scenario you described for AIX on Linux with gcc. I
> could not create the scenario since I got an error message about function
> redefinition when trying to compile my testcase. Regarding your case that
> an object is created from multiple source files containing static
> functions of the same name, don't you get an error during compile or link
> step?
>
> Assuming this is really possible, according to current GDBPicl disign, you
> will probably get two differnt parts for the static functions. In
> GDBPicl, a part is only created if its associated source file is part of
> the call stack.
>
> As you step into a function, GDBPicl gets the function's associated
> filename using "info stack". If GDBPicl does not already have a part of
> that source file, it will create the part based on the source filename.
> As you step into the other static function, you will get a different
> filename for that function. Again, if GDBPicl does not already have that
> part, it will create it and associate the static function with the newly
> created part.
>
> Please note that although GDBPicl has some methods to query functions
> information, those methods are not currently used. Functions information
> is not maintained by GDBPicl at the moment and it will function properly
> without function information. Function information was only queried to
> construct a module view, which list all the modules, parts, source files
> and functions in a tree structure. This view is currently disabled
> because it is very expensive to query for function information from GDB.
>
> Samantha
>
> John Rose wrote:
>
> > Hi -
>
> > I have a question regarding the CDT implementation. If I understand
> > things correctly, a Part (GdbPart) represents an object file in
> > EPDC-speak. Each GdbPart mantains a list of methods associated with the
> > particular Part. Specifically, GdbPart mentains a list of MethodInfo
> > objects, which identify functions according to: name, full name, return
> > type, line num, and starting line num.
>
> > Given this list of attributes for each function, consider the case of
> > one object file compiled from multiple C source files. It is possible
> > for each of these C files to have separate static C functions of the
> > same name. How would the CDT be able to distinguish between such
> > functions? It seems like the MethodInfo class would require a field for
> > the associated source file, or am I confused?
>
> > Thanks in advance-
> > John
|
|
|
Goto Forum:
Current Time: Fri May 23 09:04:08 EDT 2025
Powered by FUDForum. Page generated in 0.06035 seconds |
Home