[parisc-linux] Back to evms-1.0.1 && unaligne access && gdb

[parisc-linux] Back to evms-1.0.1 && unaligne access && gdb

[jsoe0708]

Hi all,

I need to go back to kernel 2.4.18-pa61 and evms-1.0.1 (see problem in ml:
http://lists.parisc-linux.org/pipermail/parisc-linux/2002-August/017368.html
with last 1.1.0 evsm release)

Kernel build and operate correctly. I so recompile tools with -ggdb gcc
option.
Then I use ddd to try to debug problem.

So I first run without break and got from console:
evms_vgscan(7998): unaligned access to 0x0002aaae at ip=0x4020a0e3

So I put a break early in main (Ok), relaunch run and try now to insert
a breack in gdb window:
b *0x4020a0e3

Accepted but when 'continue' is launch:
warning: Cannot insert breakpoint 2:
Cannot access memory at address 0x4020a0e3

What do I wrong or what should I better do?

Thanks in advance for help,
    Joel

RE: [parisc-linux] Back to evms-1.0.1 && unaligne access && gdb

[jsoe0708]

Hey,

I am lucky.

A ^C during a run and I got:
^C
Program received signal SIGINT, Interrupt.
0x4020a0e4 in isa_null_partition_record (p=0x3fe0ff) at checks.c:65
/usr/src/EVMS/evms-1.0.1/engine/Plugins/defsegmgr/checks.c:65:1603:beg:0x4020a0e4

where I find:
     60 BOOLEAN isa_null_partition_record(struct partition *p)
     61 {
     62     int          i;
     63     u_int32_t   *uip = (u_int32_t *) p;
     64
     65     for (i=0; i<4; i++) {
     66         if (*uip!=0x00) return FALSE;
     67     }
     68
     69     return TRUE;
     70 }

So am I right to suspect "u_int32_t   *uip = (u_int32_t *) p;" being the
actual cause of 'unaligned access' problem?

Thanks in advance for additionnal comments,
  Joel

>-- Original Message --
>From: jsoe0708@tiscali.be
>To: parisc-linux@lists.parisc-linux.org
>Subject: [parisc-linux] Back to evms-1.0.1 && unaligne access && gdb
>Date: Thu, 29 Aug 2002 11:22:45 +0200
>
>
>Hi all,
>
>I need to go back to kernel 2.4.18-pa61 and evms-1.0.1 (see problem in ml:
>http://lists.parisc-linux.org/pipermail/parisc-linux/2002-August/017368.html
>with last 1.1.0 evsm release)
>
>Kernel build and operate correctly. I so recompile tools with -ggdb gcc
>option.
>Then I use ddd to try to debug problem.
>
>So I first run without break and got from console:
>evms_vgscan(7998): unaligned access to 0x0002aaae at ip=0x4020a0e3
>
>So I put a break early in main (Ok), relaunch run and try now to insert
>a breack in gdb window:
>b *0x4020a0e3
>
>Accepted but when 'continue' is launch:
>warning: Cannot insert breakpoint 2:
>Cannot access memory at address 0x4020a0e3
>
>What do I wrong or what should I better do?
>
>Thanks in advance for help,
>    Joel
>
>
>_______________________________________________
>parisc-linux mailing list
>parisc-linux@lists.parisc-linux.org
>http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] Back to evms-1.0.1 && unaligne access && gdb

[Carlos O'Donell]

Joel,

> I need to go back to kernel 2.4.18-pa61 and evms-1.0.1 (see problem in ml:
> http://lists.parisc-linux.org/pipermail/parisc-linux/2002-August/017368.html
> with last 1.1.0 evsm release)

Why do you need to regress versions?
 
> Kernel build and operate correctly. I so recompile tools with -ggdb gcc
> option. Then I use ddd to try to debug problem.

What did you recompile with "-g"?

> So I first run without break and got from console:
> evms_vgscan(7998): unaligned access to 0x0002aaae at ip=0x4020a0e3

The unaligned handler took care of it, everything should still
be okay.

> Accepted but when 'continue' is launch:
> warning: Cannot insert breakpoint 2:
> Cannot access memory at address 0x4020a0e3
> What do I wrong or what should I better do?

AFAIK we are using software breakpoints in gdb, which means that
at certain times we _can't_ insert a breakpoint. 

I'm still unclear about the issues here. What's wrong with evms?
It dies from a SIGBUS (unaligned handler failed)? SIGSEGV? 
Operates incorrectly?

c.
 

Re: [parisc-linux] Back to evms-1.0.1 && unaligne access && gdb

[jsoe0708]

Hi Carlos,

>
>Joel,
>
>> I need to go back to kernel 2.4.18-pa61 and evms-1.0.1 (see problem in
>ml:
>> http://lists.parisc-linux.org/pipermail/parisc-linux/2002-August/017368.html
>> with last 1.1.0 evsm release)
>
>Why do you need to regress versions?
Because:
"To investigate in more details the 'unalign access' problem I met with
evms,
I need first to upgrade to evms-1.1.0 with kernel 2.4.19.

After this upgrade, all evms tools failled and I got folowing kernel message
at the console:
kernel BUG at blkpg.c:252!
evms: ldev_mgr: error(-28): creating logical disk for device(8,0)."

The willy answer:
"Aw, crap.  It now seems to be `legal' to put_user a 64-bit argument on
a
32-bit system.  Someone needs to fix this in include/asm-parisc/uaccess.h"

But I am not able ($&##?? asm) to do.

>
>> Kernel build and operate correctly. I so recompile tools with -ggdb gcc
>> option. Then I use ddd to try to debug problem.
>
>What did you recompile with "-g"?

All evms tools and libs (from tarball the 'configure' the -g is a default,
I just add gdb)

>
>> So I first run without break and got from console:
>> evms_vgscan(7998): unaligned access to 0x0002aaae at ip=0x4020a0e3
>
>The unaligned handler took care of it, everything should still
>be okay.
>
>> Accepted but when 'continue' is launch:
>> warning: Cannot insert breakpoint 2:
>> Cannot access memory at address 0x4020a0e3
>> What do I wrong or what should I better do?
>
>AFAIK we are using software breakpoints in gdb, which means that
>at certain times we _can't_ insert a breakpoint.
>
>I'm still unclear about the issues here. What's wrong with evms?
>It dies from a SIGBUS (unaligned handler failed)? SIGSEGV?
>Operates incorrectly?

First of all I would like to be sure it is absolutley harmless.
Secondly it also seems (to be verify [*]) to awfully slowing down evms management
tools.
Thanks for your attention,
    Joel

PS: [*] another lvm tool is the Sistina release which did not present this
kind of 'unaligne access' and has a behaviour nearly the same as on my i386
box on which I also test the two tools.

Re: [parisc-linux] Back to evms-1.0.1 && unaligne access && gdb

[John David Anglin]

> So I put a break early in main (Ok), relaunch run and try now to insert
> a breack in gdb window:
> b *0x4020a0e3
> 
> Accepted but when 'continue' is launch:
> warning: Cannot insert breakpoint 2:
> Cannot access memory at address 0x4020a0e3
> 
> What do I wrong or what should I better do?

Nothing.  You tried to set a break in a share library that hasn't been
loaded.  I don't have a great solution but the following should work.
Export LD_BIND_NOW so that ld.so binds symbols at program startup.  Then,
put a break on main and start the program.  You should then be able to
set a break in a shared library or enable it if the above error occurred.
For example, when you hit the break at main,

  enable 2

should insert the above.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] Back to evms-1.0.1 && unaligne access && gdb

[John David Anglin]

> So am I right to suspect "u_int32_t   *uip = (u_int32_t *) p;" being the
> actual cause of 'unaligned access' problem?

Yes, if p is not aligned, a trap will occur.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

RE: [parisc-linux] Back to evms-1.0.1 && unaligne access && gdb

[jsoe0708]

Well it does not seems to be the right place of the problem :(

I try to reproduce with the following simple C example:
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <errno.h>

typedef u_int8_t  BOOLEAN;

#ifndef TRUE
  #define TRUE  1
#endif
#ifndef FALSE
  #define FALSE 0
#endif

struct partition {
    unsigned char boot_ind;     /* 0x80 - active */
    unsigned char head;     /* starting head */
    unsigned char sector;       /* starting sector */
    unsigned char cyl;      /* starting cylinder */
    unsigned char sys_ind;      /* What partition type */
    unsigned char end_head;     /* end head */
    unsigned char end_sector;   /* end sector */
    unsigned char end_cyl;      /* end cylinder */
    unsigned int start_sect;    /* starting sector counting from 0 */
    unsigned int nr_sects;      /* nr of sectors in partition */
};

BOOLEAN isa_null_partition_record(struct partition *p)
{
    int          i;
    u_int32_t   *uip = (u_int32_t *) p;

    for (i=0; i<4; i++) {
        if (*uip!=0x00) return FALSE;
    }

    return TRUE;
}

int main(int argc, char * * argv, char * * env) {

    struct partition p1, p2;

    p1.boot_ind=0;
    p1.head=0;
    p1.sector=0;
    p1.cyl=0;
    p1.sys_ind=0;
    p1.end_head=0;
    p1.end_sector=0;
    p1.end_cyl=0;
    p1.start_sect=0;
    p1.nr_sects=0;
 
    printf("Is that p1 is a null partition: %u\n", isa_null_partition_record(&p1));

    p2.boot_ind=1;
    p2.head=2;
    p2.sector=3;
    p2.cyl=4;
    p2.sys_ind=5;
    p2.end_head=6;
    p2.end_sector=7;
    p2.end_cyl=8;
    p2.start_sect=9;
    p2.nr_sects=10;
 
    printf("Is that p2 is a null partition: %u\n", isa_null_partition_record(&p2));
    return 0;
}

and compile with same gcc option (i.e. gcc -ggdb -O2 -Wall -fPIC ) and the
problem is not reproduced?

Any idea?

Thanks in advance for additional advise,
    Joel

>-- Original Message --
>From: jsoe0708@tiscali.be
>Subject: RE: [parisc-linux] Back to evms-1.0.1 && unaligne access && gdb
>To: parisc-linux@lists.parisc-linux.org
>Date: Thu, 29 Aug 2002 11:51:36 +0200
>
>
>Hey,
>
>I am lucky.
>
>A ^C during a run and I got:
>^C
>Program received signal SIGINT, Interrupt.
>0x4020a0e4 in isa_null_partition_record (p=0x3fe0ff) at checks.c:65
>/usr/src/EVMS/evms-1.0.1/engine/Plugins/defsegmgr/checks.c:65:1603:beg:0x4020a0e4
>
>where I find:
>     60 BOOLEAN isa_null_partition_record(struct partition *p)
>     61 {
>     62     int          i;
>     63     u_int32_t   *uip = (u_int32_t *) p;
>     64
>     65     for (i=0; i<4; i++) {
>     66         if (*uip!=0x00) return FALSE;
>     67     }
>     68
>     69     return TRUE;
>     70 }
>
>So am I right to suspect "u_int32_t   *uip = (u_int32_t *) p;" being the
>actual cause of 'unaligned access' problem?
>
>Thanks in advance for additionnal comments,
>  Joel
>
>>-- Original Message --
>>From: jsoe0708@tiscali.be
>>To: parisc-linux@lists.parisc-linux.org
>>Subject: [parisc-linux] Back to evms-1.0.1 && unaligne access && gdb
>>Date: Thu, 29 Aug 2002 11:22:45 +0200
>>
>>
>>Hi all,
>>
>>I need to go back to kernel 2.4.18-pa61 and evms-1.0.1 (see problem in
ml:
>>http://lists.parisc-linux.org/pipermail/parisc-linux/2002-August/017368.html
>>with last 1.1.0 evsm release)
>>
>>Kernel build and operate correctly. I so recompile tools with -ggdb gcc
>>option.
>>Then I use ddd to try to debug problem.
>>
>>So I first run without break and got from console:
>>evms_vgscan(7998): unaligned access to 0x0002aaae at ip=0x4020a0e3
>>
>>So I put a break early in main (Ok), relaunch run and try now to insert
>>a breack in gdb window:
>>b *0x4020a0e3
>>
>>Accepted but when 'continue' is launch:
>>warning: Cannot insert breakpoint 2:
>>Cannot access memory at address 0x4020a0e3
>>
>>What do I wrong or what should I better do?
>>
>>Thanks in advance for help,
>>    Joel
>>
>>
>>_______________________________________________
>>parisc-linux mailing list
>>parisc-linux@lists.parisc-linux.org
>>http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
>
>_______________________________________________
>parisc-linux mailing list
>parisc-linux@lists.parisc-linux.org
>http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] Back to evms-1.0.1 && unaligne access && gdb

[John David Anglin]

> >Program received signal SIGINT, Interrupt.
> >0x4020a0e4 in isa_null_partition_record (p=0x3fe0ff) at checks.c:65

You can see from the value of p above that it is not properly aligned
for a 4 byte access.  Put a break on isa_null_partition_record and

cond n p==0x3fe0ff

where n is the breakpoint number of the break at isa_null_partition_record.
Then, run the program and it should stop at isa_null_partition_record
when the fault is about to occur.  You will then have to do a bt to
determine why p is incorrectly aligned (last hex digit should be 0,
4, 8 or c).

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] Back to evms-1.0.1 && unaligne access && gdb

[jsoe0708]

>-- Original Message --
>Subject: Re: [parisc-linux] Back to evms-1.0.1 && unaligne access && gdb
>To: jsoe0708@tiscali.be
>From: "John David Anglin" <dave@hiauly1.hia.nrc.ca>
>Cc: parisc-linux@lists.parisc-linux.org
>Date: Thu, 29 Aug 2002 10:28:48 -0400 (EDT)
>
>
>> >Program received signal SIGINT, Interrupt.
>> >0x4020a0e4 in isa_null_partition_record (p=0x3fe0ff) at checks.c:65
>
>You can see from the value of p above that it is not properly aligned
>for a 4 byte access.  Put a break on isa_null_partition_record and
>
>cond n p==0x3fe0ff
>
>where n is the breakpoint number of the break at isa_null_partition_record.

As previously, I could not put a break at isa_null_partition_record (function
not define but with ^C I reach to stop recursively in this function and so
for example with p==0x26ece I got p.boot_ind=0 ; p.head=63 ; p.sector=224
; p.cyl=255; ...

p is of type partition define as follow:
struct partition {
    unsigned char boot_ind;     /* 0x80 - active */
    unsigned char head;     /* starting head */
    unsigned char sector;       /* starting sector */
    unsigned char cyl;      /* starting cylinder */
    unsigned char sys_ind;      /* What partition type */
    unsigned char end_head;     /* end head */
    unsigned char end_sector;   /* end sector */
    unsigned char end_cyl;      /* end cylinder */
    unsigned int start_sect;    /* starting sector counting from 0 */
    unsigned int nr_sects;      /* nr of sectors in partition */
};

So anyway there is a bug because I presume that the for loop is there to
scan the 4 int what it doen't do (?) and find another way to say an 'int'
is null ( hmm why not simply 
u_int8_t *uip = (u_int8_t *)p;
for (i=0 ; i<16 ; i++){
    if (*uip+i != 0x00) return FALSE;
}
return TRUE;

what do you think?


>Then, run the program and it should stop at isa_null_partition_record
>when the fault is about to occur.  You will then have to do a bt to
>determine why p is incorrectly aligned (last hex digit should be 0,
>4, 8 or c).

Many thanks,
    Joel

Re: [parisc-linux] Back to evms-1.0.1 && unaligne access && gdb

[John David Anglin]

> p is of type partition define as follow:
> struct partition {
>     unsigned char boot_ind;     /* 0x80 - active */
>     unsigned char head;     /* starting head */
>     unsigned char sector;       /* starting sector */
>     unsigned char cyl;      /* starting cylinder */
>     unsigned char sys_ind;      /* What partition type */
>     unsigned char end_head;     /* end head */
>     unsigned char end_sector;   /* end sector */
>     unsigned char end_cyl;      /* end cylinder */
>     unsigned int start_sect;    /* starting sector counting from 0 */
>     unsigned int nr_sects;      /* nr of sectors in partition */
> };

The problem is that a struct of the above type is being allocated
at an unaligned address.  That's not normal.  The cast isn't the
problem.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] Back to evms-1.0.1 && unaligne access && gdb

[jsoe0708]

>
>So anyway there is a bug because I presume that the for loop is there to
>scan the 4 int what it doen't do (?) and find another way to say an 'int'
>is null ( hmm why not simply 
>u_int8_t *uip = (u_int8_t *)p;
>for (i=0 ; i<16 ; i++){
>    if (*uip+i != 0x00) return FALSE;
>}
>return TRUE;
>
Quick test and yes that works (reduce response time 1/10).

Anyway all better idea is well come :)

Thanks a lot,
    Joel

Re: [parisc-linux] Back to evms-1.0.1 && unaligne access && gdb

[Grant Grundler]

jsoe0708@tiscali.be wrote:
> >for (i=0 ; i<16 ; i++){
> >    if (*uip+i != 0x00) return FALSE;
> >}
> >return TRUE;
> >
> Quick test and yes that works (reduce response time 1/10).

You've avoided the first visible symptom but not solved the problem.
The next reference to the int embedded in the struct will cause
an unaligned access fault.

grant

Re: [parisc-linux] Back to evms-1.0.1 && unaligne access && gdb

[jsoe0708]

>-- Original Message --
>Subject: Re: [parisc-linux] Back to evms-1.0.1 && unaligne access && gdb
>To: jsoe0708@tiscali.be
>From: "John David Anglin" <dave@hiauly1.hia.nrc.ca>
>Cc: parisc-linux@lists.parisc-linux.org
>Date: Thu, 29 Aug 2002 13:10:49 -0400 (EDT)
>
>
>> p is of type partition define as follow:
>> struct partition {
>>     unsigned char boot_ind;     /* 0x80 - active */
>>     unsigned char head;     /* starting head */
>>     unsigned char sector;       /* starting sector */
>>     unsigned char cyl;      /* starting cylinder */
>>     unsigned char sys_ind;      /* What partition type */
>>     unsigned char end_head;     /* end head */
>>     unsigned char end_sector;   /* end sector */
>>     unsigned char end_cyl;      /* end cylinder */
>>     unsigned int start_sect;    /* starting sector counting from 0 */
>>     unsigned int nr_sects;      /* nr of sectors in partition */
>> };
>
>The problem is that a struct of the above type is being allocated
>at an unaligned address.

Sorry I do not understand, can you tell me more or where can I found additional
 explanation?

>  That's not normal.  The cast isn't the
>problem.
>

Thanks in advance,
    Joel

Re: [parisc-linux] Back to evms-1.0.1 && unaligne access && gdb

[jsoe0708]

>-- Original Message --
>To: jsoe0708@tiscali.be
>Cc: "John David Anglin" <dave@hiauly1.hia.nrc.ca>,
>	parisc-linux@lists.parisc-linux.org
>Subject: Re: [parisc-linux] Back to evms-1.0.1 && unaligne access && gdb
>
>Date: Thu, 29 Aug 2002 12:11:48 -0600
>From: Grant Grundler <grundler@dsl2.external.hp.com>
>
>
>jsoe0708@tiscali.be wrote:
>> >for (i=0 ; i<16 ; i++){
>> >    if (*uip+i != 0x00) return FALSE;
>> >}
>> >return TRUE;
>> >
>> Quick test and yes that works (reduce response time 1/10).
>
>You've avoided the first visible symptom but not solved the problem.
>The next reference to the int embedded in the struct will cause
>an unaligned access fault.
>

Ah ok but where is located the actual problem (gcc, ld, kernel ?).
I am not a computer science engineer and have not enough knowledge to understand
this problem of unalign access and unalign adress. Can you give me some source
of information explaining that stuff?

Thanks for adivises,
    Joel

Re: [parisc-linux] Back to evms-1.0.1 && unaligne access && gdb

[Grant Grundler]

jsoe0708@tiscali.be wrote:
> Ah ok but where is located the actual problem (gcc, ld, kernel ?).

the program.

> I am not a computer science engineer and have not enough knowledge
> to understand this problem of unalign access and unalign adress.
> Can you give me some source of information explaining that stuff?

Details for parisc:
	"PA-RISC 2.0 Architecture" by Jerry Kane.
	page 5-11, "Unaligned Data Reference Trap (28)"
	page 7-84, "Load Word"

heh...doesn't define "aligned address" in the Glossary.
The same stuff is in the PA 1.1 Arch books too.

"aligned" means the address of the data falls on a boundary
that is modulo the size of the data. It's more complicated
for a "struct" but the rule applies to any field in a struct.

Examples:
	0x10 is an aligned address for an "int"
	0x12 is an aligned address for a "short" but not an "int".

Got it?

BTW, even though x86 CPUs don't trap on unaligned access,
they do take a performance hit. IIRC, it's one additional cycle.
Under linux, most (all?) RISC CPUs trap and handle the unaligned access
in the kernel trap handler. Other OS's could SIGBUS the application
to kill it.

Hmm...this is interesting:
/usr/include/linux/prctl.h:# define PR_UNALIGN_SIGBUS   2       /* generate SIGBUS on unaligned user access */

Maybe you can figure out how to set this and dig through the
core file instead of trying to set break points.

grant

Re: [parisc-linux] Back to evms-1.0.1 && unaligne access && gdb

[jsoe0708]

>-- Original Message --
>To: jsoe0708@tiscali.be
>Cc: "John David Anglin" <dave@hiauly1.hia.nrc.ca>,
>	parisc-linux@lists.parisc-linux.org
>Subject: Re: [parisc-linux] Back to evms-1.0.1 && unaligne access && gdb
>
>Date: Fri, 30 Aug 2002 00:30:51 -0600
>From: Grant Grundler <grundler@dsl2.external.hp.com>
>
>
>jsoe0708@tiscali.be wrote:
>> Ah ok but where is located the actual problem (gcc, ld, kernel ?).
>
>the program.
>
>> I am not a computer science engineer and have not enough knowledge
>> to understand this problem of unalign access and unalign adress.
>> Can you give me some source of information explaining that stuff?
>
>Details for parisc:
>	"PA-RISC 2.0 Architecture" by Jerry Kane.
>	page 5-11, "Unaligned Data Reference Trap (28)"
>	page 7-84, "Load Word"
>
>heh...doesn't define "aligned address" in the Glossary.
>The same stuff is in the PA 1.1 Arch books too.
>
>"aligned" means the address of the data falls on a boundary
>that is modulo the size of the data. It's more complicated
>for a "struct" but the rule applies to any field in a struct.
>
>Examples:
>	0x10 is an aligned address for an "int"
>	0x12 is an aligned address for a "short" but not an "int".
>
>Got it?
>
>BTW, even though x86 CPUs don't trap on unaligned access,
>they do take a performance hit. IIRC, it's one additional cycle.
>Under linux, most (all?) RISC CPUs trap and handle the unaligned access
>in the kernel trap handler. Other OS's could SIGBUS the application
>to kill it.
>
Thanks a lot for all info 

>Hmm...this is interesting:
>/usr/include/linux/prctl.h:# define PR_UNALIGN_SIGBUS   2       /* generate
>SIGBUS on unaligned user access */
>
>Maybe you can figure out how to set this and dig through the
>core file instead of trying to set break points.
>
Not sure I will reach but i will have look anyway.

Many thanks again,
    Joel

Re: [parisc-linux] Back to evms-1.0.1 && unaligne access && gdb

[John David Anglin]

> >> p is of type partition define as follow:
> >> struct partition {
> >>     unsigned char boot_ind;     /* 0x80 - active */
> >>     unsigned char head;     /* starting head */
> >>     unsigned char sector;       /* starting sector */
> >>     unsigned char cyl;      /* starting cylinder */
> >>     unsigned char sys_ind;      /* What partition type */
> >>     unsigned char end_head;     /* end head */
> >>     unsigned char end_sector;   /* end sector */
> >>     unsigned char end_cyl;      /* end cylinder */
> >>     unsigned int start_sect;    /* starting sector counting from 0 */
> >>     unsigned int nr_sects;      /* nr of sectors in partition */
> >> };
> >
> >The problem is that a struct of the above type is being allocated
> >at an unaligned address.
> 
> Sorry I do not understand, can you tell me more or where can I found additional

You may be able to find a copy of WG14/N869 (Committee Draft -- January 18,
1999) on the web.  It is a draft version of the ISO C standard.  Section
6.7.2.1 describes struct and union types.

In general, the C standard doesn't define the representation used for
objects.  However, the alignment requirement of field members (except
bit fields) is the same as its type when not in a struct or union.
The PA implementation uses a strict "natural" alignment for types.
E.g., 4 byte integers are aligned to 4 byte boundaries.  Multiple
instructions are needed for unaligned data access on the PA.

A pointer to a struct points to the initial member (ie., there is no
padding before the first member).

The above struct starts with an unsigned char type so as far as the
standard goes it could start at any byte.  Note that it contains int
types, so that if it didn't start on a 4 byte boundary, there would
have to be padding after the last char field.  If the struct was given
"char" alignment, then different code would be needed to access members
when it was and wasn't aligned to a 4 byte boundary.  To minimize
problems of this nature, gcc aligns structs based on the largest
alignment requirement of all its members.

The code generated by gcc will not properly access fields of a struct
that isn't properly aligned.  Thus, you will need to try and find
out why in this particular case the struct isn't aligned and correct
the problem.  It might be a malloc problem or data read into an
arbitrary location.

Because the initial field of the struct is an unsigned char type,
the cast to uint32_t is wrong.  The code is making implementation
dependent assumptions.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] Back to evms-1.0.1 && unaligne access && gdb

[Joel Soete]

> 
> Because the initial field of the struct is an unsigned char type,
> the cast to uint32_t is wrong.  The code is making implementation
> dependent assumptions.
> 
Finaly this trial version of function:


BOOLEAN isa_null_partition_record(struct partition *p)
{
      if (p->boot_ind == 0x00 &&
          p->head == 0x00 &&
          p->sector == 0x00 &&
          p->cyl == 0x00 &&
          p->sys_ind == 0x00 &&
          p->end_head == 0x00 &&
          p->end_sector == 0x00 &&
          p->end_cyl == 0x00 &&
          p->start_sect == 0x00 &&
          p->nr_sects == 0x00 )
          return TRUE;
      else
          return FALSE;
}

would be more portable and more easy to read and understand :<)

Thanks again for your help,
	Joel

Re: [parisc-linux] Back to evms-1.0.1 && unaligne access && gdb

[Grant Grundler]

Joel Soete wrote:
> Finaly this trial version of function:
> 
> 
> BOOLEAN isa_null_partition_record(struct partition *p)
> {
>       if (p->boot_ind == 0x00 &&
>           p->head == 0x00 &&
>           p->sector == 0x00 &&
>           p->cyl == 0x00 &&
>           p->sys_ind == 0x00 &&
>           p->end_head == 0x00 &&
>           p->end_sector == 0x00 &&
>           p->end_cyl == 0x00 &&
>           p->start_sect == 0x00 &&
>           p->nr_sects == 0x00 )
>           return TRUE;

Since start_sect and nr_sects are ints, this code will also generate an
"unaligned data reference fault" like the original code did. You need
to find the origin of "struct partition *p" when the address is un-aligned.

grant

Re: [parisc-linux] Back to evms-1.0.1 && unaligne access && gdb

[jsoe0708]

>-- Original Message --
>To: Joel Soete <joel.soete@freebel.net>
>Cc: John David Anglin <dave@hiauly1.hia.nrc.ca>, jsoe0708@tiscali.be,
>	parisc-linux@lists.parisc-linux.org
>Subject: Re: [parisc-linux] Back to evms-1.0.1 && unaligne access && gdb
>
>From: Grant Grundler <grundler@dsl2.external.hp.com>
>Date: Sat, 31 Aug 2002 17:50:15 -0600
>
>
>Joel Soete wrote:
>> Finaly this trial version of function:
>>
>>
>> BOOLEAN isa_null_partition_record(struct partition *p)
>> {
>>       if (p->boot_ind == 0x00 &&
>>           p->head == 0x00 &&
>>           p->sector == 0x00 &&
>>           p->cyl == 0x00 &&
>>           p->sys_ind == 0x00 &&
>>           p->end_head == 0x00 &&
>>           p->end_sector == 0x00 &&
>>           p->end_cyl == 0x00 &&
>>           p->start_sect == 0x00 &&
>>           p->nr_sects == 0x00 )
>>           return TRUE;
>
>Since start_sect and nr_sects are ints, this code will also generate an
>"unaligned data reference fault" like the original code did.

Trust me it does not? (it works fine)

>You need
>to find the origin of "struct partition *p" when the address is un-aligned.
>
Very hard to define:
a. the previous code works (again all odds)
b. the following trial code:
"
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <errno.h>

typedef u_int8_t  BOOLEAN;

#ifndef TRUE
  #define TRUE  1
#endif
#ifndef FALSE
  #define FALSE 0
#endif

struct partition {
    unsigned char boot_ind;     /* 0x80 - active */
    unsigned char head;     /* starting head */
    unsigned char sector;       /* starting sector */
    unsigned char cyl;      /* starting cylinder */
    unsigned char sys_ind;      /* What partition type */
    unsigned char end_head;     /* end head */
    unsigned char end_sector;   /* end sector */
    unsigned char end_cyl;      /* end cylinder */
    unsigned int start_sect;    /* starting sector counting from 0 */
    unsigned int nr_sects;      /* nr of sectors in partition */
};

BOOLEAN isa_null_partition_record(struct partition *p)
{
    int          i;
    u_int32_t   *uip = (u_int32_t *) p;

    for (i=0; i<4; i++) {
        if (*uip!=0x00) return FALSE;
    }

    return TRUE;
}

int main(int argc, char * * argv, char * * env) {

    struct partition p1, p2;

    p1.boot_ind=0;
    p1.head=0;
    p1.sector=0;
    p1.cyl=0;
    p1.sys_ind=0;
    p1.end_head=0;
    p1.end_sector=0;
    p1.end_cyl=0;
    p1.start_sect=0;
    p1.nr_sects=0;

    printf("Is that p1 is a null partition: %u\n", isa_null_partition_record(&p1));

    p2.boot_ind=1;
    p2.head=2;
    p2.sector=3;
    p2.cyl=4;
    p2.sys_ind=5;
    p2.end_head=6;
    p2.end_sector=7;
    p2.end_cyl=8;
    p2.start_sect=9;
    p2.nr_sects=10;

    printf("Is that p2 is a null partition: %u\n", isa_null_partition_record(&p2));
    return 0;
}
"
did not reproduce the problem.


Even if in the previous code, I replace:
BOOLEAN isa_null_partition_record(struct partition *p)
{
    int          i;
    u_int32_t   *uip = (u_int32_t *) p;

    for (i=0; i<4; i++) {
        if (*uip!=0x00) return FALSE;
    }

    return TRUE;
}
by
extern BOOLEAN isa_null_partition_record(struct partition *p);

and also link it with the original library containing isa_null_partition_record,
I can no more reproduce the problem.

The only difference I can notice is that 'isa_null_partition_record' is
not directly used by evms tools but through modules loaded at run time (the
cause of gdb debug difficulties) (or am I wrong and a subtil detail escape
to my attention)?

What can I do to analyse this problem? (printing all p addresses and its
elements
during a run with the original code and compare with a run with modified
code?)

Thanks again for attention and help,
    Joel

Re: [parisc-linux] Back to evms-1.0.1 && unaligne access && gdb

[Grant Grundler]

jsoe0708@tiscali.be wrote:
> >Since start_sect and nr_sects are ints, this code will also generate an
> >"unaligned data reference fault" like the original code did.
> 
> Trust me it does not? (it works fine)

then I'll wager there is padding between the char and int fields
of that struct.

> >You need
> >to find the origin of "struct partition *p" when the address is un-aligned.
> >
> Very hard to define:
> a. the previous code works (again all odds)
> b. the following trial code:
...

> int main(int argc, char * * argv, char * * env) {
> 
>     struct partition p1, p2;

...
> did not reproduce the problem.

Things on the stack (local var) are properly aligned.
Malloc a block of mem and then point to an unaligned address
in that block.

> What can I do to analyse this problem? (printing all p addresses and its
> elements
> during a run with the original code and compare with a run with modified
> code?)

yes. You want to verify the addreses are unaligned.

grant

[parisc-linux] Unaligne access [was: Back to evms-1.0.1 && unaligne access && gdb ]

[jsoe0708]

Hello Grant,

>
>then I'll wager there is padding between the char and int fields
>of that struct.

That is also what I believe to understand.

>
...
>> What can I do to analyse this problem? (printing all p addresses and its
>> elements
>> during a run with the original code and compare with a run with modified
>> code?)
>
>yes. You want to verify the addreses are unaligned.

And here is some data of my analyse:

First surprise in the two case (original checks.c and my checks.c with only
"if (p->boot_ind != 0x00 && ") p addresses are exactly the same here is an
example:
with checks.c.orig:
dmesg
...
evms_vgscan(10137): unaligned access to 0x000272ee at ip=0x4020a2ab

corresponding adresses:
p            add: 0x272ee
p.boot_ind   add: 0x272ee
p.head       add: 0x272ef
p.sector     add: 0x272f0
p.cyl        add: 0x272f1
p.sys_ind    add: 0x272f2
p.end_head   add: 0x272f3
p.end_sector add: 0x272f4
p.end_cyl    add: 0x272f5
p.start_sect add: 0x272f6
p.nr_sects   add: 0x272fa

with the checks.c.new:
p            add: 0x272ee
p.boot_ind   add: 0x272ee
p.head       add: 0x272ef
p.sector     add: 0x272f0
p.cyl        add: 0x272f1
p.sys_ind    add: 0x272f2
p.end_head   add: 0x272f3
p.end_sector add: 0x272f4
p.end_cyl    add: 0x272f5
p.start_sect add: 0x272f6
p.nr_sects   add: 0x272fa

What do you think?

Thanks again for attention and help,
    Joel

PS1: just in case I made error here is the code I add to print addresses:
    printf("p            add: %p\n", p);
    printf("p.boot_ind   add: %p\n", &(p->boot_ind));
    printf("p.head       add: %p\n", &(p->head));
    printf("p.sector     add: %p\n", &(p->sector));
    printf("p.cyl        add: %p\n", &(p->cyl));
    printf("p.sys_ind    add: %p\n", &(p->sys_ind));
    printf("p.end_head   add: %p\n", &(p->end_head));
    printf("p.end_sector add: %p\n", &(p->end_sector));
    printf("p.end_cyl    add: %p\n", &(p->end_cyl));
    printf("p.start_sect add: %p\n", &(p->start_sect));
    printf("p.nr_sects   add: %p\n", &(p->nr_sects));

PS2: If you think it could help you more, I can send you the complete logs
I get from the two runs as well as sources

[parisc-linux] Re: Unaligne access [was: Back to evms-1.0.1 && unaligne access && gdb ]

[Grant Grundler]

jsoe0708@tiscali.be wrote:
...
> And here is some data of my analyse:
> 
> First surprise in the two case (original checks.c and my checks.c with only
> "if (p->boot_ind != 0x00 && ") p addresses are exactly the same here is an
> example:

...
> with the checks.c.new:
> p            add: 0x272ee
> p.boot_ind   add: 0x272ee
> p.head       add: 0x272ef
> p.sector     add: 0x272f0
> p.cyl        add: 0x272f1
> p.sys_ind    add: 0x272f2
> p.end_head   add: 0x272f3
> p.end_sector add: 0x272f4
> p.end_cyl    add: 0x272f5
> p.start_sect add: 0x272f6
> p.nr_sects   add: 0x272fa
> 
> What do you think?

checks.c.new will generate a "misaligned access" when "p.start_sect"
is accessed. 0x272f6 is aligned on 2byte address, not 4 byte.
Ditto for "p.nr_sects".

You sure checks.c.new is referencing 0x272f6 and not something else?
You reviewed dmesg output?

...
> PS1: just in case I made error here is the code I add to print addresses:

printf's look right.

> PS2: If you think it could help you more, I can send you the complete logs
> I get from the two runs as well as sources

thanks but no. I'm just trying to help you understand "unaligned access".

grant

[parisc-linux] Re: Unaligne access [was: Back to evms-1.0.1 && unaligne access && gdb ]

[John David Anglin]

> >then I'll wager there is padding between the char and int fields
> >of that struct.
> 
> That is also what I believe to understand.

Unlikely.  The unaligned trap handler in the kernel is probably
fixing the unaligned access.  You need to look in the kernel log
to see if this is happening.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

[parisc-linux] Re: Unaligne access [was: Back to evms-1.0.1 && unaligne access && gdb ]

[jsoe0708]

Dave,
>
>
>> >then I'll wager there is padding between the char and int fields
>> >of that struct.
>> 
>> That is also what I believe to understand.
>
>Unlikely.  The unaligned trap handler in the kernel is probably
>fixing the unaligned access.  You need to look in the kernel log
>to see if this is happening.
>
Nothing to notice about unalign access kernel trap in any /var/log files
(with checks.c.new) Is there some "debug" #define to set to increase verbosity
of this trap?

Thanks a lot,
    Joel

[parisc-linux] Re: Unaligne access [was: Back to evms-1.0.1 && unaligne access && gdb ]

[jsoe0708]

>jsoe0708@tiscali.be wrote:
>...
>> And here is some data of my analyse:
>> 
>> First surprise in the two case (original checks.c and my checks.c with
>only
>> "if (p->boot_ind != 0x00 && ") p addresses are exactly the same here is
>an
>> example:
>
>...
>> with the checks.c.new:
>> p            add: 0x272ee
>> p.boot_ind   add: 0x272ee
>> p.head       add: 0x272ef
>> p.sector     add: 0x272f0
>> p.cyl        add: 0x272f1
>> p.sys_ind    add: 0x272f2
>> p.end_head   add: 0x272f3
>> p.end_sector add: 0x272f4
>> p.end_cyl    add: 0x272f5
>> p.start_sect add: 0x272f6
>> p.nr_sects   add: 0x272fa
>> 
>> What do you think?
>
>checks.c.new will generate a "misaligned access" when "p.start_sect"
>is accessed. 0x272f6 is aligned on 2byte address, not 4 byte.
>Ditto for "p.nr_sects".
>
(now I have understand, well I think :) )

>You sure checks.c.new is referencing 0x272f6 and not something else?

For this I will have to find all call to this function and write p.start_sect
address and content before.

(very tricky problem to surround isn'it ;<) )

>You reviewed dmesg output?

Yes (I have a mincom 'screen' on this system console and I also examine kern.log
as recall Dave)


Many thanks,
    Joel

PS: In the mean time I learn that this bug was already fix by:
BOOLEAN isa_null_partition_record(struct partition *p)
{
    int          i;
    u_int8_t    *uip = (u_int8_t *) p;
    int          psize = sizeof(struct partition);

    for (i=0; i<psize; i++) {
        if (*(uip+i) != 0x00) return FALSE;
    }

    return TRUE;
}

but not yet comited :?

[parisc-linux] Re: Unaligne access [was: Back to evms-1.0.1 && unaligne access && gdb ]

[jsoe0708]

>>jsoe0708@tiscali.be wrote:
>>...
>>> And here is some data of my analyse:
>>> 
>>> First surprise in the two case (original checks.c and my checks.c with
>>only
>>> "if (p->boot_ind != 0x00 && ") p addresses are exactly the same here
is
>>an
>>> example:
>>
>>...
>>> with the checks.c.new:
...
>>
>>checks.c.new will generate a "misaligned access" when "p.start_sect"
>>is accessed. 0x272f6 is aligned on 2byte address, not 4 byte.
>>Ditto for "p.nr_sects".
>>
>(now I have understand, well I think :) )
>
>>You sure checks.c.new is referencing 0x272f6 and not something else?
>
>For this I will have to find all call to this function and write p.start_sect
>address and content before.
>
>(very tricky problem to surround isn'it ;<) )
>
And so here is a test (where an unaligne access did not occurs where it would??):
(isa_valid_partition_record) file checks.c
### before the call ###
part.start_sect add: 0x242a6
part.start_sect    : 9439488   [1]
part.nr_sects   add: 0x242aa
part.nr_sects      : 15791872  [2]
### Into the function isa_null_partition_record() ###
p            add: 0x2429e
p.boot_ind   add: 0x2429e
p.head       add: 0x2429f
p.sector     add: 0x242a0
p.cyl        add: 0x242a1
p.sys_ind    add: 0x242a2
p.end_head   add: 0x242a3
p.end_sector add: 0x242a4
p.end_cyl    add: 0x242a5
p.start_sect add: 0x242a6
p.start_sect    : 9439488      [3]
p.nr_sects   add: 0x242aa
p.nr_sects      : 15791872     [4]

As far as I can see [1] and [3] (as well as [2] and [4]) seems to show that
it point actualy to the same thing.

And here is an other sample:

(isa_valid_partition_record) file checks.c
part.start_sect add: 0x24556
part.start_sect    : 536870912
part.nr_sects   add: 0x2455a
part.nr_sects      : 3768004864
p            add: 0x2454e
p.boot_ind   add: 0x2454e
p.head       add: 0x2454f
p.sector     add: 0x24550
p.cyl        add: 0x24551
p.sys_ind    add: 0x24552
p.end_head   add: 0x24553
p.end_sector add: 0x24554
p.end_cyl    add: 0x24555
p.start_sect add: 0x24556
p.start_sect    : 536870912
p.nr_sects   add: 0x2455a
p.nr_sects      : 3768004864
p            add: 0x2454e
p.boot_ind   add: 0x2454e
p.head       add: 0x2454f
p.sector     add: 0x24550
p.cyl        add: 0x24551
p.sys_ind    add: 0x24552
p.end_head   add: 0x24553
p.end_sector add: 0x24554
p.end_cyl    add: 0x24555
p.start_sect add: 0x24556
p.start_sect    : 536870912
p.nr_sects   add: 0x2455a
p.nr_sects      : 3768004864

Joel



Big Brother Anders  - With Tiscali you will see it all !  Check it up on
 www.tiscali.be/bigbrother

Re: [parisc-linux] Re: Unaligne access [was: Back to evms-1.0.1 && unaligne access && gdb ]

[Randolph Chung]

> >Unlikely.  The unaligned trap handler in the kernel is probably
> >fixing the unaligned access.  You need to look in the kernel log
> >to see if this is happening.
> >
> Nothing to notice about unalign access kernel trap in any /var/log files
> (with checks.c.new) Is there some "debug" #define to set to increase verbosity
> of this trap?

no, it will log by default.. nothing to configure.

randolph
--  
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/