Problem with the Itanium debugger

[Alex Vournas]

I am having problems with the Itanium vms debugger. When I examine a pointer in the code below, the debugger assumes the incorrect type.



#include

typedef struct
{
int
rec1_field;
} REC1;

typedef struct
{
int
rec2_field;
} REC2;

typedef struct { REC1 *list; } REC1_LIST;
typedef struct { REC2 *list; } REC2_LIST;

int main(int argc, char *argv[])
{
REC1_LIST
rec1_list;
REC1
rec1;

rec1.rec1_field = 1;

rec1_list.list = &rec1;

return 0;
}


On itanium I get this:

OpenVMS I64 Debug64 Version X8.3-015

%DEBUG-I-INITIAL, Language: C, Module: BUG_EXAMPLE

%DEBUG-I-NOTATMAIN, Type GO to reach MAIN program

DBG> 1> SET BREAK %Name"BUG_EXAMPLE"\%LINE 1628

DBG> 1> DEACTIVATE BREAK %Name"BUG_EXAMPLE"\%LINE 1624

DBG> go

break at BUG_EXAMPLE\main\%LINE 1628

DBG> ex *rec1_list.list

*BUG_EXAMPLE\main\rec1_list.list

rec2_field: 1

DBG>



Notice how it says the contents of rec1_list.list is rec2_field. It should be rec1_field.

On alpha, it works:



OpenVMS Alpha Debug64 Version V8.3-014



%DEBUG-I-INITIAL, Language: C, Module: BUG_EXAMPLE

%DEBUG-I-NOTATMAIN, Type GO to reach MAIN program

DBG> 1> SET BREAK %Name"BUG_EXAMPLE"\%LINE 1628

DBG> 1> DEACTIVATE BREAK %Name"BUG_EXAMPLE"\%LINE 1624

DBG> go

break at BUG_EXAMPLE\main\%LINE 1628

DBG> ex *rec1_list.list

*BUG_EXAMPLE\main\rec1_list.list

rec1_field: 1

DBG>


Is this a bug in the itanium debugger?

[Hoff]

I'd try altering the naming of REC1_LIST and rec1_list here to move away from case-sensitive naming. This on no evidence and no testing on OpenVMS I64.

Please also post your OpenVMS version and your C version and your patch level.

[Alex Vournas]

I tried renaming the type and variable differently as you suggested; it didn't make a difference. These are the versions:

OpenVMS V8.3-1H1
HP C V7.3-018 on OpenVMS IA64 V8.3-1H1

[John Gillings]

Alex,
Could be a bug.

Log a case with HP Customer Support. Send them a minimal reproducer, with exact instructions for demonstrating your symptom (I like to send a self contained command procedure that starts from scratch automates all steps).

Make it clear what you believe to be incorrect, and what you believe the correct result should be. Also include a complete list of versions of all products (a PRODUCT SHOW PRODUCT listing will do).

This could be a compiler issue, a debug issue or a combination of the two. Make sure you've tried it with the latest compiler, and any DEBUG patches relevant to your OS version.

Note that there's a new field test C++ compiler. It might be worth trying your code against it.

[Hoff]

Patch to current.

I'd next rework the code to remove the typedef struct typedef struct declaration construction, as I suspect that's at the core of this problem.

Time permitting, I'll power up a local Itanium "target practice" box and try this code over there.

And if you have a support contract, escalate this to HP.

[Pramod Kumar M]

Hi,

This is really strange

I removed all the typedefs and added one more structure still there is a problem.

$ type main.c
#include

struct rec1 {
int rec1_field;
} REC1;

struct rec2 {
int rec2_field;
} REC2;

struct rec3 {
int rec3_field;
} REC3;


struct {
struct rec1 *list;
} REC1_LIST;

struct {
struct rec2 *list;
} REC2_LIST;

struct {
struct rec3 *list;
} REC3_LIST;

int main(int argc, char *argv[])
{

REC1.rec1_field = 1;

REC1_LIST.list = &REC1;

REC2.rec2_field = 2;

REC2_LIST.list = &REC2;

REC3.rec3_field = 3;

REC3_LIST.list = &REC3;

return 0;
}

DBG> ex *REC1_LIST.list
*MAIN\REC1_LIST.list
rec3_field: 1
DBG> ex *REC2_LIST.list
*MAIN\REC2_LIST.list
rec3_field: 2
DBG> ex *REC3_LIST.list
*MAIN\REC3_LIST.list
rec3_field: 3
DBG>

It shows the correct value, but looks like symbolization is wrong.

I think it is a bug.

Regards,
Pramod.

[Hoff]

Please stop duplicating the symbol names. That has classically confused many compilation passes.

[Alex Vournas]

I agree that this is a bug. I will contact support. I will post a reply with the results.

Thanks

[Bennett_2]

Do you see any difference between say ...

test1 that uses $CC /NOOPT/DEB $LINK /DEB

and test2 that $CC /OPTIMIZE[=option] (D)

This could be more of a code optimizer behavior then a DEBUGGER "issue".

[Dennis Handly]

>Is this a bug in the Integrity debugger?

It sure looks like it.

You may want to use C++ coding style, not the scummy C style:
typedef struct foo foo
struct foo {
    int f1;
    foo *next;
};
foo foo_variable;

Note: Every struct has a tag. Variables are declared separately from the struct. And to satisfy scummy C rules, you have a typedef for the same tag. The typedef can be after if you don't need that self-referential field.

>Pramod: I removed all the typedefs and added one more structure still there is a problem.

You still have some structs without tags.

>Bennett: This could be more of a code optimizer behavior then a DEBUGGER issue.

I doubt it. The optimizer wouldn't change the struct layouts, just cause it to print bad values that have been optimized away.

[Alex Vournas]

HP support confirmed that this was a bug. They gave me a patch that fixed this. Thanks for your help.