Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 157983 - gcc produces inadequate alignment for __thread vars
Summary: gcc produces inadequate alignment for __thread vars
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: binutils
Version: 3.0
Hardware: ia64
OS: Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact:
Depends On:
Blocks: 156320
TreeView+ depends on / blocked
Reported: 2005-05-17 15:49 UTC by Yoav Zach
Modified: 2007-11-30 22:07 UTC (History)
1 user (show)

Fixed In Version: RHSA-2005-659
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-09-28 14:02:55 UTC
Target Upstream Version:

Attachments (Terms of Use)
binutils- (deleted)
2005-05-19 13:33 UTC, Jakub Jelinek
no flags Details | Diff

System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2005:659 qe-ready SHIPPED_LIVE Low: binutils security update 2005-09-28 04:00:00 UTC

Description Yoav Zach 2005-05-17 15:49:34 UTC
Description of problem:
In some code sequences, gcc creates __thread variables with inadequate offset, 
causing applications to crash when accessing these variables.

Version-Release number of selected component (if applicable):
[/tmp/gcc-bug-2]gcc -v
Reading specs from /usr/lib/gcc-lib/ia64-redhat-linux/3.2.3/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --
infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-
checking --with-system-zlib --enable-__cxa_atexit --host=ia64-redhat-linux
Thread model: posix
gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-42)

How reproducible:

Steps to Reproduce:
[/tmp/gcc-bug-2]cat main.c
struct foo_t {
        unsigned long ll[2] __attribute__ ((aligned (16)));
typedef struct foo_t foo_t;

__thread long t1  = 0l, t2 = 0l;
__thread foo_t fooo;

int g_dont_core = 0;
char * search_path[] = { "/usr/local/bin", "/usr/bin",
        "/bin", "/usr/lib/foo", ""
long bar (void *addr)
        return bar2 (addr);
cc -fpic -ffixed-r13 -nostdinc   -c -o main.o main.c
gcc -shared -o main.o

Actual results:

The alignment of the thread variable 'fooo' has to be 16. Nevertheless, the 
value gcc assigns to it is 0x18, causing it to be non-aligned :

reading the output of readelf on the resulted shared object, one can see the 
alignment of TLS segment is 0x10:

  TLS            0x0000000000000ee8 0x0000000000010ee8 0x0000000000010ee8
                 0x0000000000000018 0x0000000000000028  R      10

but the value assigned to 'fooo' is 0x18:

   55: 0000000000000018    16 TLS     GLOBAL DEFAULT   18 fooo

which together sums up to 0x8 alignment, instead of 0x10.

ofcourse - this is a very simplified test case, the real case has a jmp_buf 
aligned incorrectly on 8 bytes, resulting with SIGBUS as soon as it is accessed.

Additional info:
I found the problem on RHEL3 U5 beta ( which is the latest one I have ), and 
checking with previous EL3 versions, i see the same behavior on EL3U3.

Comment 1 Yoav Zach 2005-05-18 20:39:53 UTC
I've just realized that I had to open an entry in the issue-tracker and not in 
bugzilla. I opened entry #73030 for that. Sorry for the confusion.

Comment 2 Jakub Jelinek 2005-05-19 12:53:18 UTC
That's actually a linker bug, not compiler bug.
Fixed by:
(so works properly in RHEL4), but I'll try to come up with some much smaller
patch for RHEL3.

Comment 3 Jakub Jelinek 2005-05-19 13:33:20 UTC
Created attachment 114565 [details]

Patch that ought to fix this.

Comment 11 Red Hat Bugzilla 2005-09-28 14:02:55 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

Note You need to log in before you can comment on or make changes to this bug.