bugGNU arch -- a revision control system - Bugs: bug #15915, MACHINE_ALIGNMENT miscalculated on...

 
 

bug #15915: MACHINE_ALIGNMENT miscalculated on PPC32

Submitted by:  None
Submitted on:  Mon 27 Feb 2006 02:10:29 PM UTC  
 
Category: tlaSeverity: 3 - Normal
Item Group: bugStatus: Ready For Test
Privacy: PublicOpen/Closed: Open
Release: 1.3.4
Fixed Release: 1.3.5
Merge Request?: None
Your Archive Name: 
Your Archive Location: 
Assigned to: Andy Tai <atai>

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Sun 29 Jun 2008 11:41:13 PM UTC, comment #5:

http://groups-beta.google.com/group/animal-sex-tube-x
http://groups-beta.google.com/group/zootube-beastiality
http://groups-beta.google.com/group/extreme-animalsex
http://groups-beta.google.com/group/zoo-animal-sex-tube-x
http://groups-beta.google.com/group/zoo-tube-365-com-x
http://groups-beta.google.com/group/kds-bbs-pics-x
http://groups-beta.google.com/group/forbidden-cp-pics-x
http://groups-beta.google.com/group/underage-russian-cp-video
http://groups-beta.google.com/group/pedoland-bbs-pthc-c
http://groups-beta.google.com/group/preteen-bbs
http://groups-beta.google.com/group/sex-movies-x
http://groups-beta.google.com/group/spank-teens-hardcore
http://groups-beta.google.com/group/little-oral-annie---best-porn-video
http://groups-beta.google.com/group/enema-punishment-stories
http://groups-beta.google.com/group/free-bdsm-videos
http://groups-beta.google.com/group/free-bondage-videos
http://groups-beta.google.com/group/pissing-in-public
http://groups-beta.google.com/group/cumshot-compilation
http://groups-beta.google.com/group/amateur-and-free-and-video
http://groups-beta.google.com/group/interracial-gang-bang-x
http://groups-beta.google.com/group/animalporn-tube-c
http://groups-beta.google.com/group/free-animal-porn-tube-c
http://groups-beta.google.com/group/yuo-tube-porno
http://groups-beta.google.com/group/animals-bestiality-tube
http://groups-beta.google.com/group/beast-tube-videos

Anonymous
Wed 22 Mar 2006 09:42:52 AM UTC, comment #4:

fix
machine/gen-alignment.to-c
in hackerlab

+
+/*
+ technique borrowed from
+
+ Computing Memory Alignment Restrictions
+ of Data Types in C and C++
+ by Tom Lokovic
+
+http://www.monkeyspeak.com/alignment/

+*/
#undef TYPE
#define TYPE(SCALAR, STRUCT) \
- this = gcd(sizeof (SCALAR), sizeof (struct flux__align_ ## STRUCT)); \
+ this = ((sizeof(struct_ ## STRUCT) > sizeof(SCALAR)) ? \
+ sizeof(struct_ ## STRUCT) - sizeof(SCALAR) : sizeof(SCALAR)) ;\
if (this > best) \
best = this;

ready for test on 32-bit PowerPC. Who can let me have access to such an environment?

Andy Tai <atai>
Project AdministratorIn charge of this item.
Fri 03 Mar 2006 01:53:53 PM UTC, comment #3:

This issue was a bug in the Red Hat development glibc. I think this can be closed now.

One suggestion from the RH bugzilla:

"BTW, sizeof (long double) is completely wrong thing to check when you check alignment, you need to check _alignof_ (long double). On many architectures, some types have different alignment than their size, e.g. on sparc32 or s390 long double is 8 byte aligned, but 16 byte in size."

Josh Boyer <jwboyer>
Mon 27 Feb 2006 07:00:43 PM UTC, comment #2:

Yes, the "fix" in the RH bugzilla is not a fix at all. It simply allowed the package to build without any negative effects for Fedora Extras at this moment. That is why I opened this bug to begin with :).

Josh Boyer <jwboyer>
Mon 27 Feb 2006 06:27:08 PM UTC, comment #1:

Wow. I always knew that `gen-alignment' would eventually
come back and bite me somehow -- I just never knew exactly
how. Now I do.

If I'm following the reports correctly, the real bug
is in the invariant check. The invariant check makes
a false assumption that the machine's strictest alignment
requirements are determined by the size of the largest
scalar type.

The macro MACHINE_ALIGNMENT is poorly named. It should
really be something like:
CONSERVATIVE_ESTIMATE_OF_MACHINE_ALIGNMENT

The primary use of MACHINE_ALIGNMENT is to safely wrap
`malloc' in an allocator that adds a header to allocated
memory. `ar.c' is an example of such an allocator.
The user asks for N bytes. We want a K byte header.
So we allocate:

N + ALIGNMENT * ((K + ALIGNMENT - 1) / ALIGNMENT)

bytes, put the header at byte 0, and start the user data
at byte:

ALIGNMENT * ((K + ALIGNMENT - 1) / ALIGNMENT)

The invariant that we are truly trying to maintain is that,
so long as `malloc' returns memory suitably aligned for anything,
so does our wrapper (such as the `ar' functions).

The actual invariant test in the code tests for a stricter
condition that happens not to be true in this case. It's
the invariant, not `gen-alignment', that is bogus.

A fix that showed up on the Red Hat bugzilla involved computing
MACHINE_ALIGNMENT differently. That "fix" introduces a bug
(that may or may not actually effect existing architectures)
and should not be made. It's the call to `invariant' that
contains the bug.

-t

Tom Lord <tomlord>
Project Member
Mon 27 Feb 2006 02:10:29 PM UTC, original submission:

The gen-alignment program that calculates the MACHINE_ALIGNMENT macro generates the wrong alignment on PPC32. With the newest glibc, the ABI changed for PPC such that sizeof(long double) returns 16 instead of 8. However, malloc only guarantees alignment for 2 * sizeof(void *), which is still 8 bytes.

When attempting to build tla on PPC32, the unit-ar test fails because of this as it is checking for 16 byte alignment when it should be checking for 8 byte alignment. See:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182742

for more details.

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

Do you think this task is very important?
If so, you can click here to add your encouragement to it.
This task has 0 encouragements so far.

Only logged-in users can vote.

 

Please enter the title of George Orwell's famous dystopian book (it's a date):

 

 

Follow 4 latest changes.

Date Changed By Updated Field Previous Value => Replaced By
Wed 22 Mar 2006 09:42:52 AM UTCataiStatusNone=>Ready For Test
  Fixed Release=>1.3.5
Mon 20 Mar 2006 05:09:52 AM UTCataiAssigned toNone=>atai
Mon 27 Feb 2006 02:13:02 PM UTCjwboyerCarbon-Copy-=>Added -unavailable-

Back to the top


Powered by Savane 3.1-cleanup