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: (Doc ping [for news and manual]) -- [PATCH 14/14] the "compile" command


Eli> That's not what I meant.  Suppose I have 2 compilers installed, one
Eli> called 'gcc', the other 'gcc472'.  (They could also be in different
Eli> directories, even not on PATH.)  The program I'm debugging was
Eli> compiled with gcc472.  How will GDB know to invoke that executable?
Eli> Also, how would it know the command-line arguments required to produce
Eli> a code that will work well with the rest of the program being debugged
Eli> (the code I compile can call functions in the program, right?)?

Phil> Tom could maybe answer this better.  There was recent work on the GCC
Phil> triplet and PATH searching over on GCC for the plugin.

Yes, the new version searches the path for something matching the
correct GNU configury triplet.  See the gcc patch series for details.

Eli> But GDB knows how to access registers regardless of the language.  Why
Eli> cannot the compiled code use those facilities?  It sounds like a
Eli> limitation, especially when the program being debugged was compiled
Eli> with optimizations.

It's a limitation.  We didn't add any gdb C parser extensions to gcc.
We've discussed it but haven't decided on whether to pursue it yet.

Tom


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