headers
Ray Bejjani | 1 Jun 2007 03:32
Picon

Re: Turning off printing of char pointer contents

Thanks! That should do it. I can set regions, but I cant set (or even
show) the inaccessible-by-default setting . It's in the manual, and
I've tried it with 6.5 and 6.6 (in case it was new) but it simply
doesn't know what it is. I don't know if it matters, but I'm
cross-debugging a coldfire, so maybe it isn't supported (of course, I
cant seem to set it in my x86 one either).
I get:
(gdb) set mem inaccessible-by-default on
No symbol "mem" in current context.

Thanks again, sorry for being quite useless.

On 5/31/07, Jim Blandy <jimb <at> codesourcery.com> wrote:
>
> "Ray Bejjani" <ray.bejjani <at> gmail.com> writes:
> > I'm trying to turn off printing the contents of char pointers. I'm use
> > GDB to debug an embedded app remotely. In some instances the pointers
> > are left uninitialised and can point to sections of memory that cause
> > system crashes when accessed (or they cause external hardware to
> > change state when read). I am using DDD on top of GDB but I can
> > reproduce the issue with GDB as well. GDB seems to treat C strings in
> > a special manner, attempting to print the contents until it sees an
> > null terminator or hit the limit set by the "print elements" setting.
> > My system crashes when this happens.
> > Unfortunately, doing a set print elements 0 is interpreted as no
> > limit. Are there any other settings I can use to suppress this
> > feature? In particular, I would like it to treat char (or unsigned
> > char) pointers like it does other pointers where it doesn't attempt to
> > dereference them. I would still like to be able to display/print the
> > contents of strings when needed but only on demand. Failing that,
(Continue reading)

Permalink | Reply | 2 comments |
headers
Bogdan Slusarczyk | 1 Jun 2007 09:58
Picon
Favicon

tracing variables - is it ok?

Hi everybody, suppose such code:

void testB( int a ) { //a == 20
    int k = a;
}
void testA( int a ) { //a == 10
    int k = a;
     testB( 20 );
}
void main() {
    testA( 10 );
}

Inside testA I did '-var-create -  <at>  a' and inside testB '-var-update', 
but gdb (6.3, 6.6) says that nothing changes and returns a==10 from 
testA. Is it intended behaviour? How can I properly trace variable 
changes? It applies not only for function arguments - I tryied do the 
same thing with 'k', there is the same problem. It strange for me 
because '-var-create -  <at> ' handles scope changes properly (see below)
{
    int a = 10;
    {
       int a = 20;
    }
}

Regards,
Bogdan
(Continue reading)

Permalink | Reply | 4 comments |
headers
Vladimir Prus | 1 Jun 2007 10:37
Picon
Favicon

Re: tracing variables - is it ok?

Bogdan Slusarczyk wrote:

> Hi everybody, suppose such code:
> 
> void testB( int a ) { //a == 20
>     int k = a;
> }
> void testA( int a ) { //a == 10
>     int k = a;
>      testB( 20 );
> }
> void main() {
>     testA( 10 );
> }
> 
> Inside testA I did '-var-create -  <at>  a' and inside testB '-var-update',
> but gdb (6.3, 6.6) says that nothing changes and returns a==10 from
> testA. 

This seems weird. Can you also print 'a' right after creating varobj,
and right after -var-update, to make sure it's the problem with
variable objects, and not with something else. Please do this test with
gdb 6.6, or better yet, with CVS version.

Thanks,
Volodya
Permalink | Reply | 3 comments |
headers
Bogdan Slusarczyk | 1 Jun 2007 11:13
Picon
Favicon

Re: tracing variables - is it ok?

Vladimir Prus pisze:
> This seems weird. Can you also print 'a' right after creating varobj,
> and right after -var-update, to make sure it's the problem with
> variable objects, and not with something else. Please do this test with
> gdb 6.6, or better yet, with CVS version.
I did -var-evaluate-expression just after creating varobj and I got 
proper value (testA, a=10 ). After -var-update (in testB) value is not 
changed. I did this test with gdb  6.6.

Regards
Bogdan
Permalink | Reply | 2 comments |
headers
Vladimir Prus | 1 Jun 2007 11:17
Picon
Favicon

Re: tracing variables - is it ok?

On Friday 01 June 2007 13:13, Bogdan Slusarczyk wrote:
> Vladimir Prus pisze:
> > This seems weird. Can you also print 'a' right after creating varobj,
> > and right after -var-update, to make sure it's the problem with
> > variable objects, and not with something else. Please do this test with
> > gdb 6.6, or better yet, with CVS version.
> I did -var-evaluate-expression just after creating varobj and I got 
> proper value (testA, a=10 ). After -var-update (in testB) value is not 
> changed. I did this test with gdb  6.6.

Please do "print a". The -var-evaluate-expression won't show changed
value if -var-update did not mention a given variable object.

- Volodya
Permalink | Reply | 1 comment |
headers
Bogdan Slusarczyk | 1 Jun 2007 11:28
Picon
Favicon

Re: tracing variables - is it ok?

Vladimir Prus pisze:
> On Friday 01 June 2007 13:13, Bogdan Slusarczyk wrote:
>   
>> Vladimir Prus pisze:
>>     
>>> This seems weird. Can you also print 'a' right after creating varobj,
>>> and right after -var-update, to make sure it's the problem with
>>> variable objects, and not with something else. Please do this test with
>>> gdb 6.6, or better yet, with CVS version.
>>>       
>> I did -var-evaluate-expression just after creating varobj and I got 
>> proper value (testA, a=10 ). After -var-update (in testB) value is not 
>> changed. I did this test with gdb  6.6.
>>     
>
> Please do "print a". The -var-evaluate-expression won't show changed
> value if -var-update did not mention a given variable object.
print 'a' from testA returns 10, from testB returns 20

Bogdan
Permalink | Reply | 0 comments |
headers
Matt Kern | 1 Jun 2007 14:20

DWARF2 FDE Address Mismatch

I am in the process of porting a new MCU/processor to gcc/gdb.  It has a
a Harvard architecture with a 24 bit code address space (word aligned
instructions) and a 16 bit data address space.  Our toolchain emits ELF
binaries with code and data VMAs based at zero.  The program loads as
though it is a ROM image located entirely in code space.

The setup we have gone for involves having all pointers be 16 bits.
Code pointers actually address "trampolines" to the respective
functions.  Our preferred debug format is DWARF2;  we have therefore set
DWARF2_ADDR_SIZE to 4 in order to correctly represent our full range of
code addresses.  Without this setting, addresses are stored as
POINTER_SIZE / BITS_PER_UNIT == 2 bytes.

The output produced by gcc looks to be correct at this juncture.
However, we have problems loading the DWARF2 info in gdb.  Most notably,
gdb defaults cie->encoding to DW_EH_PE_absptr (which is sizeof(void*) ==
2 bytes).   The encoding can be changed by augmentation, but gcc only
emits this for EH data; DWARF2_ADDR_SIZE applies to non-EH data.

In short it looks like GDB DWARF2 support lacks a mechanism to override
the address size (comparable to DWARF2_ADDR_SIZE in gcc).  Is my
understanding correct?

Regards,
Matt

--

-- 
Matt Kern
http://www.undue.org/
(Continue reading)

Permalink | Reply | 5 comments |
headers
Martin Rivers | 1 Jun 2007 15:14
Favicon

Debugging an OpenMP program with gcc4.2 and gdb 6.6

My system is a RedHat Enterprise Linux 3 system.  I've built a native gcc 4.2.0
compiler and am using binutils 2.17.50 as well as gdb 6.6.  In trying to learn
about OpenMP, I created what I believed to be a very trivial program below.  I
then attempted to set a breakpoint at the 'num threads %d' printf (line 15).  I
then ran the program.  The breakpoint was hit but when doing a 'next' command,
control returns to the top of main (line 4).  Entering another "next" command
results in control returning to line 15 (the 'num threads' printf).  However,
before that break at line 15 is hit, I get the results two 'num threads' strings

displayed to the console.  Finally, entering the 'next' command again places
control at the #pragma omp barrier line (no printfs).

Thus I never actually seem to hit the breakpoint at the printf line in the
context of each thread to see it do the printf (the printfs occur, I just don't
see what I would consider appropriate breakpoint/next run control.

I then re-ran the program and this time set breakpoints at line 9 (x=5) and line

12 (sleep) and line 18 (if clause).  The first breakpoint I hit is line 15.
Entering 'continue' command hits the breakpoint at line 12 (sleep).  Entering
the 'continue' command again causes the breakpoint at line 9 to get hit.
Entering 'continue' yet again lands me at line 18.  Again, I do see appropriate
breakpoints in the context of each thread for lines 9 and 12 but never see
breakpoints for the printf (line 15) for the two threads.

My compile line is:

gcc42 -fopenmp -O0 -g -pthread -o try try.c

I admit I'm new to openmp but the above run control during the debug sessions
(Continue reading)

Permalink | Reply | 1 comment |
headers
Daniel Jacobowitz | 1 Jun 2007 15:38

Re: Turning off printing of char pointer contents

On Thu, May 31, 2007 at 06:32:07PM -0700, Ray Bejjani wrote:
> Thanks! That should do it. I can set regions, but I cant set (or even
> show) the inaccessible-by-default setting . It's in the manual, and
> I've tried it with 6.5 and 6.6 (in case it was new) but it simply
> doesn't know what it is. I don't know if it matters, but I'm
> cross-debugging a coldfire, so maybe it isn't supported (of course, I
> cant seem to set it in my x86 one either).

It's even newer than that.  You'll have to grab a CVS snapshot from
the FTP site (or from CVS).

--

-- 
Daniel Jacobowitz
CodeSourcery
Permalink | Reply | 1 comment |
headers
Daniel Jacobowitz | 1 Jun 2007 15:42

Re: Debugging an OpenMP program with gcc4.2 and gdb 6.6

On Fri, Jun 01, 2007 at 09:14:27AM -0400, Martin Rivers wrote:
> I admit I'm new to openmp but the above run control during the debug sessions
> above don't seem right.  Is this what is expected?  Am I missing some gdb
> patch?  Am I missing some other special debugging option?

My guess is that either GCC is not emitting adequate debug info for
OpenMP, or the debug info necessary is so complex that GDB doesn't
understand it.  I don't know if GDB and GOMP have been used together
yet.

--

-- 
Daniel Jacobowitz
CodeSourcery
Permalink | Reply | 0 comments |

Gmane