* [Bug default/20323] void* idiom for intel, PGI DWARF confuses subsequent parameter handling
2016-01-01 0:00 [Bug default/20323] New: void* idiom for intel, PGI DWARF confuses subsequent parameter handling woodard at redhat dot com
` (2 preceding siblings ...)
2016-01-01 0:00 ` dodji at redhat dot com
@ 2016-01-01 0:00 ` woodard at redhat dot com
2016-01-01 0:00 ` woodard at redhat dot com
4 siblings, 0 replies; 6+ messages in thread
From: woodard at redhat dot com @ 2016-01-01 0:00 UTC (permalink / raw)
To: libabigail
https://sourceware.org/bugzilla/show_bug.cgi?id=20323
--- Comment #1 from Ben Woodard <woodard at redhat dot com> ---
Created attachment 9377
--> https://sourceware.org/bugzilla/attachment.cgi?id=9377&action=edit
jemalloc shared libraries
Here is a tar file with all the shared libraries.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug default/20323] void* idiom for intel, PGI DWARF confuses subsequent parameter handling
2016-01-01 0:00 [Bug default/20323] New: void* idiom for intel, PGI DWARF confuses subsequent parameter handling woodard at redhat dot com
2016-01-01 0:00 ` [Bug default/20323] " dodji at redhat dot com
@ 2016-01-01 0:00 ` dodji at redhat dot com
2016-01-01 0:00 ` dodji at redhat dot com
` (2 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: dodji at redhat dot com @ 2016-01-01 0:00 UTC (permalink / raw)
To: libabigail
https://sourceware.org/bugzilla/show_bug.cgi?id=20323
--- Comment #2 from dodji at redhat dot com ---
What I read from looking at the debug info generated for the jemalloc binary
generated using the PGI compiler is that there is no parameter for the deallocx
function:
PGI:
[ 502] subprogram
external (flag)
name (string) "dallocx"
decl_file (data1) 1
decl_line (data2) 2477
low_pc (addr) +0x00000000000132d0 <dallocx>
high_pc (addr) +0x000000000001334a <__dallocxEND>
frame_base (block1)
[ 0] reg6
Whereas for for GCC, the debug info says dallocx has two parameters. The first
one is of type pointer to void, and the second one is of type int.
[ 4a9f] subprogram
external (flag_present)
name (strp) "dallocx"
decl_file (data1) 1
decl_line (data2) 2477
prototyped (flag_present)
low_pc (addr) +0x000000000000ca20 <dallocx>
high_pc (data8) 1449 (+0x000000000000cfc9)
frame_base (exprloc)
[ 0] call_frame_cfa
GNU_all_tail_call_sites (flag_present)
sibling (ref4) [ 54c5]
[ 4abd] formal_parameter
name (string) "ptr"
decl_file (data1) 1
decl_line (data2) 2477
type (ref4) [ f6]
location (sec_offset) location list [ 47f6]
[ 4acd] formal_parameter
name (strp) "flags"
decl_file (data1) 1
decl_line (data2) 2477
type (ref4) [ 46]
location (sec_offset) location list [ 4996]
[...]
[ f6] pointer_type
byte_size (data1) 8
[...]
[ 46] base_type
byte_size (data1) 4
encoding (data1) signed (5)
name (string) "int"
That is why abidiff says that the dallocx function lost its two parameters when
comparing the one compiled with GCC against the one compiled with PGI.
So I would argue that the PGI compiler does not emit the description of the
parameters of the dallocx function and it should.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug default/20323] New: void* idiom for intel, PGI DWARF confuses subsequent parameter handling
@ 2016-01-01 0:00 woodard at redhat dot com
2016-01-01 0:00 ` [Bug default/20323] " dodji at redhat dot com
` (4 more replies)
0 siblings, 5 replies; 6+ messages in thread
From: woodard at redhat dot com @ 2016-01-01 0:00 UTC (permalink / raw)
To: libabigail
https://sourceware.org/bugzilla/show_bug.cgi?id=20323
Bug ID: 20323
Summary: void* idiom for intel, PGI DWARF confuses subsequent
parameter handling
Product: libabigail
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: default
Assignee: dodji at redhat dot com
Reporter: woodard at redhat dot com
CC: libabigail at sourceware dot org
Target Milestone: ---
I believe that this is actually distinct from 20194 but the patch to fix that
may ultimately lead to this being resolved as well. At the very least they
should be looked at together.
I'm looking at:
[C]'function void dallocx(void*, int)' at jemalloc.c:2477:1 has some indirect
sub-type changes:
parameter 1 of type 'void*' changed:
entity changed from 'void*' to 'int'
type size changed from 64 to 32 bits
parameter 2 of type 'int' was removed
GCC has:
[ 4a9f] subprogram
external (flag_present)
name (strp) "dallocx"
decl_file (data1) 1
decl_line (data2) 2477
prototyped (flag_present)
low_pc (addr) +0x000000000000ca20 <dallocx>
high_pc (data8) 1449 (+0x000000000000cfc9)
frame_base (exprloc)
[ 0] call_frame_cfa
GNU_all_tail_call_sites (flag_present)
sibling (ref4) [ 54c5]
[ 4abd] formal_parameter
name (string) "ptr"
decl_file (data1) 1
decl_line (data2) 2477
type (ref4) [ f6]
location (sec_offset) location list [ 47f6]
[ 4acd] formal_parameter
name (strp) "flags"
decl_file (data1) 1
decl_line (data2) 2477
type (ref4) [ 46]
location (sec_offset) location list [ 4996]
[ 46] base_type
byte_size (data1) 4
encoding (data1) signed (5)
name (string) "int"
[ f6] pointer_type
byte_size (data1) 8
Intel has:
[ 12832] subprogram
decl_line (data2) 2477
decl_column (data1) 1
decl_file (data1) 20
prototyped (flag)
name (strp) "dallocx"
MIPS_linkage_name (strp) "dallocx"
low_pc (addr) +0x000000000000b0b0 <dallocx>
high_pc (addr) +0x000000000000b310 <sdallocx>
external (flag)
[ 12851] formal_parameter
decl_line (data2) 2477
decl_column (data1) 18
decl_file (data1) 20
type (ref4) [ 5fc]
name (string) "ptr"
location (block1)
[ 0] reg5
[ 12860] formal_parameter
decl_line (data2) 2477
decl_column (data1) 27
decl_file (data1) 20
type (ref4) [ 3e5]
name (strp) "flags"
location (block1)
[ 0] reg4
[ 5fc] pointer_type
type (ref4) [ 539]
[ 539] base_type
byte_size (data1) 0
encoding (data1) signed (5)
name (strp) "void"
[ 3e5] base_type
byte_size (data1) 4
encoding (data1) signed (5)
name (string) "int"
So the error is wrong: Parameter 2 of type int was not removed. I believe that
the processing is getting confused by the intel/pgi idiom of expressing a
void*.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug default/20323] void* idiom for intel, PGI DWARF confuses subsequent parameter handling
2016-01-01 0:00 [Bug default/20323] New: void* idiom for intel, PGI DWARF confuses subsequent parameter handling woodard at redhat dot com
@ 2016-01-01 0:00 ` dodji at redhat dot com
2016-01-01 0:00 ` dodji at redhat dot com
` (3 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: dodji at redhat dot com @ 2016-01-01 0:00 UTC (permalink / raw)
To: libabigail
https://sourceware.org/bugzilla/show_bug.cgi?id=20323
Bug 20323 depends on bug 20194, which changed state.
Bug 20194 Summary: Fail to recognize void type represented by DW_TAG_base_type
https://sourceware.org/bugzilla/show_bug.cgi?id=20194
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution|--- |FIXED
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug default/20323] void* idiom for intel, PGI DWARF confuses subsequent parameter handling
2016-01-01 0:00 [Bug default/20323] New: void* idiom for intel, PGI DWARF confuses subsequent parameter handling woodard at redhat dot com
` (3 preceding siblings ...)
2016-01-01 0:00 ` woodard at redhat dot com
@ 2016-01-01 0:00 ` woodard at redhat dot com
4 siblings, 0 replies; 6+ messages in thread
From: woodard at redhat dot com @ 2016-01-01 0:00 UTC (permalink / raw)
To: libabigail
https://sourceware.org/bugzilla/show_bug.cgi?id=20323
Ben Woodard <woodard at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Depends on| |20194
Referenced Bugs:
https://sourceware.org/bugzilla/show_bug.cgi?id=20194
[Bug 20194] Intel void* idiom has wrong size
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug default/20323] void* idiom for intel, PGI DWARF confuses subsequent parameter handling
2016-01-01 0:00 [Bug default/20323] New: void* idiom for intel, PGI DWARF confuses subsequent parameter handling woodard at redhat dot com
2016-01-01 0:00 ` [Bug default/20323] " dodji at redhat dot com
2016-01-01 0:00 ` dodji at redhat dot com
@ 2016-01-01 0:00 ` dodji at redhat dot com
2016-01-01 0:00 ` woodard at redhat dot com
2016-01-01 0:00 ` woodard at redhat dot com
4 siblings, 0 replies; 6+ messages in thread
From: dodji at redhat dot com @ 2016-01-01 0:00 UTC (permalink / raw)
To: libabigail
https://sourceware.org/bugzilla/show_bug.cgi?id=20323
dodji at redhat dot com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |WAITING
--- Comment #3 from dodji at redhat dot com ---
I am putting this problem report in the WAITING state until we hear more from
the PGI people. I still think that the PGI compiler should emit debug info
describing the parameters of the function here, unless there is something I am
missing.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2016-07-08 8:41 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-01-01 0:00 [Bug default/20323] New: void* idiom for intel, PGI DWARF confuses subsequent parameter handling woodard at redhat dot com
2016-01-01 0:00 ` [Bug default/20323] " dodji at redhat dot com
2016-01-01 0:00 ` dodji at redhat dot com
2016-01-01 0:00 ` dodji at redhat dot com
2016-01-01 0:00 ` woodard at redhat dot com
2016-01-01 0:00 ` woodard at redhat dot com
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).