Hi, I have some problem using GCC and GDB, you know, the current GDB has
python pretty printer enabled, so that the variables can be show quite
nicely.
My problem is when gdb try to show some variable that is not
initialized. For example:
void test()
{
std::string stdStr("std::string");
On 18 June 2010 22:50, wrote:
> Hello GCC of GNU,
>
> I've done a bit of research regarding the GCC complier, and even emailed
> GNU regarding the usage of GCC to comply self developed games for game
> console OS (such as Xbox 360, Playstation3, Nintendo Wii and etc.).
>
> I did learn that GCC is
Hello GCC of GNU,
I've done a bit of research regarding the GCC complier, and even emailed
GNU regarding the usage of GCC to comply self developed games for game
console OS (such as Xbox 360, Playstation3, Nintendo Wii and etc.).
I did learn that GCC is a major complier for Playstation (which is
I see nothing in the GCC 4.5 release notes about
plugin support being language specific, and yet if I using the treehydra
plugin with Ada (admittedly using a patched GCC 4.3.4 as per the dehydra
notes), I get this
gnat1: warning: command line option
"-fplugin=/home/linux/gcc-dehydra/dehydra/gcc_
On 06/18/10 09:41, Joern Rennecke wrote:
> I found in an as-yet unreleased port that I had to use an UNSPEC as a
> placeholder for the return address; it is conceivable that you want
> to express the location of return address as the sum of the stack pointer
> and an as-yet unknown constant integer
DWARF Version 4 Released
June 16, 2010
The DWARF Debugging Information Format Committee is pleased to announce the
availability of Version 4 of the DWARF Debugging Information Format standard.
The DWARF debugging format is used to communicate information between a compiler
and debugger to make
Michael Eager wrote:
The final version of DWARF Version 4 is available
for download from http://dwarfstd.org.
A technical problem generating the PDF of the DWARF
Version 4 standard has been corrected. Please see
following announcement.
--
Michael Eagerea...@eagercon.com
1960 Park Blvd.,
This may be useful:
http://gcc.gnu.org/wiki/DebuggingGCC
And in general the info here:
http://gcc.gnu.org/wiki/GettingStarted
It is a wiki, so contributions and fixes are very welcome.
Thanks,
Manuel.
On 18 June 2010 10:55, Radu Hobincu wrote:
>> "Radu Hobincu" writes:
>>
>>> The compiler
Quoting Bernd Schmidt :
On 06/18/2010 08:38 AM, Joern Rennecke wrote:
You are not only rejecting invalid pic constants, you reject everything
that's not CONST_INT. That could also include a
(const (unspec ...)) for some integer the target has to calculate after
register allocation / frame lay
> I'd say we should switch to version 4 only when we need the new fields
> (i.e. if ia64 or other VLIW starts using the new VLIW .debug_line features,
> let it use version 4, but for other targets 3 would be good enough).
> Similarly for .debug_frame.
I agree that makes sense. The .debug_info v4
> "Radu Hobincu" writes:
>
>> The compiler crashes with "Segmentation fault".
>
>> 2. When I try "char c = 'c';", the compiler fails an assert:
>
> It's time to break out the debugger and look at the source code and
> figure out what the compiler is doing. Neither of these problems ring
> any sor
On Wed, Jun 16, 2010 at 05:06:29PM -0700, Roland McGrath wrote:
> Are there any plans to make GCC and/or GAS emit the version 4 variants of
> the .debug_line and/or .debug_frame formats?
>
> The .debug_line version 4 format only adds the "maximum operations per
> instruction" header field and asso
On 06/18/2010 08:38 AM, Joern Rennecke wrote:
> You are not only rejecting invalid pic constants, you reject everything
> that's not CONST_INT. That could also include a
> (const (unspec ...)) for some integer the target has to calculate after
> register allocation / frame layout.
Examples? I'v
13 matches
Mail list logo
