[Bug c/96383] New: Full ABI information missing missing from GCC compiled C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96383 Bug ID: 96383 Summary: Full ABI information missing missing from GCC compiled C Product: gcc Version: 10.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: woodard at redhat dot com Target Milestone: --- When GCC compiles C and there is a call to an external function the full ABI information for the function being called doesn't exist in the caller. For example compiling bzip2 with gcc 10.1.1 this is all that you get for the function fflush. [ 93a4]subprogram abbrev: 96 external (flag_present) yes declaration (flag_present) yes linkage_name (strp) "fflush" name (strp) "fflush" decl_file(data1) stdio.h (6) decl_line(data1) 218 decl_column (data1) 12 However when you compile the same library with clang you get much more information: [ 49ec]subprogram abbrev: 26 name (strp) "fflush" decl_file(data1) stdio.h (3) decl_line(data1) 218 prototyped (flag_present) yes type (ref4) [ 425e] declaration (flag_present) yes external (flag_present) yes [ 49f7] formal_parameter abbrev: 7 type (ref4) [ 47c7] [ 47c7]pointer_type abbrev: 3 type (ref4) [ 47cc] [ 47cc]structure_type abbrev: 21 name (strp) "_IO_FILE" byte_size(data1) 216 decl_file(data1) struct_FILE.h (4) decl_line(data1) 49 [ 47d4] member abbrev: 13 name (strp) "_flags" type (ref4) [ 425e] decl_file(data1) struct_FILE.h (4) decl_line(data1) 51 data_member_location (data1) 0 [ 47e0] member abbrev: 13 name (strp) "_IO_read_ptr" type (ref4) [ 4685] decl_file(data1) struct_FILE.h (4) decl_line(data1) 54 data_member_location (data1) 8 ... This information is useful because it allows you to verify that the library that the caller is expecting has the same ABI as the function that the callee is providing.
[Bug c/96383] Full ABI information missing missing from GCC compiled C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96383 --- Comment #2 from Ben Woodard --- Created attachment 48955 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48955&action=edit gcc binary
[Bug c/96383] Full ABI information missing missing from GCC compiled C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96383 --- Comment #1 from Ben Woodard --- Created attachment 48954 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48954&action=edit clang binary
[Bug debug/96383] Full ABI information missing missing from GCC compiled C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96383 --- Comment #3 from Ben Woodard --- This also affects C++ but in that case some info can be derived due to mangling.
[Bug target/49146] segv from libgcc_s when raising an exception, or unwinding stack with backtrace with ms_abi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49146 --- Comment #4 from Ben Woodard --- Created attachment 30127 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30127&action=edit Patch from Ariel that prevents the segv
[Bug target/49146] segv from libgcc_s when raising an exception, or unwinding stack with backtrace with ms_abi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49146 --- Comment #5 from Ben Woodard --- Ariel, In talking to the engineers regarding this, they would like _builtin_expect hints to tell the compiler to generate code saying that hitting this is unlikely. http://blog.man7.org/2012/10/how-much-do-builtinexpect-likely-and.html
[Bug target/49146] segv from libgcc_s when raising an exception, or unwinding stack with backtrace with ms_abi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49146 --- Comment #6 from Ben Woodard --- Created attachment 30134 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30134&action=edit reproducer program still working on getting access to the machine where I have ICC. My password expired.
[Bug target/49146] segv from libgcc_s when raising an exception, or unwinding stack with backtrace with ms_abi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49146 --- Comment #7 from Ben Woodard --- Created attachment 30137 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30137&action=edit t_repro.c compiled -g -O2
[Bug target/49146] segv from libgcc_s when raising an exception, or unwinding stack with backtrace with ms_abi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49146 Ben Woodard changed: What|Removed |Added Attachment #30127|0 |1 is obsolete|| --- Comment #9 from Ben Woodard --- Created attachment 30177 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30177&action=edit updated patch that includes __builtin_expect
[Bug bootstrap/57900] New: /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57900 Bug ID: 57900 Summary: /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: woodard at redhat dot com This is an easy problem to solve and there are a couple of ways to solve it. The underlying problem is that I don't have one of the glibc-devel packages installed or I can build with --disable-multilib However, I would argue that autoconf/configure should have picked this up in much the same way that it picks up the fact that GMP, MPFR and MPC may be missing and prints out: configure: error: Building GCC requires GMP 4.2+, MPFR 2.3.1+ and MPC 0.8.0+. Try the --with-gmp, --with-mpfr and/or --with-mpc options to specify their locations. Source code for these libraries can be found at their respective hosting sites as well as at ftp://gcc.gnu.org/pub/gcc/infrastructure/. See also http://gcc.gnu.org/install/prerequisites.html for additional info. If you obtained GMP, MPFR and/or MPC from a vendor distribution package, make sure that you have installed both the libraries and the header files. They may be located in separate packages. --- error text --- /home/ben/Work/gcc/host-x86_64-unknown-linux-gnu/gcc/xgcc -B/home/ben/Work/gcc/host-x86_64-unknown-linux-gnu/gcc/ -B/home/ben/Work/gcc-test/x86_64-unknown-linux-gnu/bin/ -B/home/ben/Work/gcc-test/x86_64-unknown-linux-gnu/lib/ -isystem /home/ben/Work/gcc-test/x86_64-unknown-linux-gnu/include -isystem /home/ben/Work/gcc-test/x86_64-unknown-linux-gnu/sys-include-g -O2 -m32 -O2 -g -O2 -DIN_GCC -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fpic -mlong-double-80 -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fpic -mlong-double-80 -I. -I. -I../../../host-x86_64-unknown-linux-gnu/gcc -I../../.././libgcc -I../../.././libgcc/. -I../../.././libgcc/../gcc -I../../.././libgcc/../include -I../../.././libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS -DUSE_TLS -o _gcov.o -MT _gcov.o -MD -MP -MF _gcov.dep -DL_gcov -c ../../.././libgcc/libgcov.c In file included from /usr/include/features.h:399:0, from /usr/include/stdio.h:27, from ../../.././libgcc/../gcc/tsystem.h:87, from ../../.././libgcc/libgcov.c:27: /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory # include ^ compilation terminated. make[5]: *** [_gcov.o] Error 1 make[5]: Leaving directory `/home/ben/Work/gcc/x86_64-unknown-linux-gnu/32/libgcc' make[4]: *** [multi-do] Error 1 make[4]: Leaving directory `/home/ben/Work/gcc/x86_64-unknown-linux-gnu/libgcc' make[3]: *** [all-multi] Error 2 make[3]: *** Waiting for unfinished jobs make[3]: Leaving directory `/home/ben/Work/gcc/x86_64-unknown-linux-gnu/libgcc' make[2]: *** [all-stage1-target-libgcc] Error 2 make[2]: Leaving directory `/home/ben/Work/gcc' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/home/ben/Work/gcc' make: *** [bootstrap] Error 2
[Bug bootstrap/57900] /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57900 Ben Woodard changed: What|Removed |Added Severity|minor |trivial
[Bug fortran/58067] New: ICE in GFortran recog.c:2158
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58067
Bug ID: 58067
Summary: ICE in GFortran recog.c:2158
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: woodard at redhat dot com
Created attachment 30602
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30602&action=edit
a flattened self contained version of the NAS benchmark.
When I try to compile one of the NAS benchmark's with -fpic and -mcmodel=large
with GCC 4.8.0 up through the current trunk (20130802) I get an internal
compiler error. This looks rather similar to PR56797 but that particular bug
seems to have been only on ARM and this occurs on x86_64. So it may be that
PR56797 is more expansive than initially thought or this might be a different
bug. I can't tell.
[ben@snog BT-MZ]$ PATH=/home/ben/Work/gcc-test/bin/:$PATH gfortran -c
-save-temps -O2 -g -fopenmp -fpic -mcmodel=large bt-all.f
bt-all.f: In function ‘MAIN__._omp_fn.1’:
bt-all.f:305:0: note: non-delegitimized UNSPEC UNSPEC_PLTOFF (9) found in
variable location
do iz = 1, proc_num_zones
^
bt-all.f:305:0: note: non-delegitimized UNSPEC UNSPEC_PLTOFF (9) found in
variable location
bt-all.f: In function ‘MAIN__._omp_fn.0’:
bt-all.f:449:0: error: unrecognizable insn:
999 continue
^
(call_insn/u 52 51 53 2 (parallel [
(set (reg:DI 0 ax)
(call:DI (mem:QI (symbol_ref:DI ("__tls_get_addr")) [0 S1 A8])
(const_int 0 [0])))
(unspec:DI [
(symbol_ref:DI ("omp_cmn2a_") [flags 0x10] )
] UNSPEC_TLS_GD)
]) bt-all.f:48 -1
(expr_list:REG_EH_REGION (const_int -2147483648 [0x8000])
(nil))
(nil))
bt-all.f:449:0: internal compiler error: in extract_insn, at recog.c:2158
0x922c1a _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../.././gcc/rtl-error.c:109
0x922c49 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../.././gcc/rtl-error.c:117
0x8f966a extract_insn(rtx_def*)
../.././gcc/recog.c:2158
0x7bdbee instantiate_virtual_regs_in_insn
../.././gcc/function.c:1609
0x7bdbee instantiate_virtual_regs
../.././gcc/function.c:1926
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
This problem doesn't seem to occur except when you have -fpic and
-mcmodel=large. Changing the memory model to medium or small or removing the
-fpic allows the code to compile.
Attached is a flattened self contained version of the NAS benchmark my fortran
is not good enough to boil it down into a more parsimonious reproducer.
[Bug target/58067] ICE in GFortran recog.c:2158
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58067 --- Comment #3 from Ben Woodard --- (In reply to Uroš Bizjak from comment #2) > You can add -mtls-dialect=gnu2 to -fpic and -mcmodel=large. Though doing that prevents the ICE, the compilation spits out about 78 lines like: bt-all.f:453:0: note: non-delegitimized UNSPEC UNSPEC_GOTOFF (1) found in variable location Google doesn't seem to give me any idea as to if I need be concerned about that note.
[Bug target/58067] ICE in GFortran recog.c:2158
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58067 --- Comment #6 from Ben Woodard --- I just rebuilt the trunk with the patch that Alexandre Oliva provided and I can confirm that it solves the problem with notes about non-delegitimized addresses. However, I haven't yet tested the DWARF to make sure that it works as expected. If we do make -mtls-dialect=gnu2 the default or even implied when you specify -mcmodel=large, won't you still need to fix the problem with the unknown instruction just in case someone does -mtls-dialect=gnu or will you just error out saying: "-mcmodel=large is not supported within -mtls-dialect=gnu". Personally, I believe that erroring out that way is perfectly acceptable.
[Bug target/58067] ICE in GFortran recog.c:2158
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58067 --- Comment #7 from Ben Woodard --- Created attachment 30622 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30622&action=edit Alexandre's patch as a file rather than as text.
[Bug middle-end/81478] By default, GCC emits a function call for complex multiplication, should partially inline that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81478 Ben Woodard changed: What|Removed |Added CC||woodard at redhat dot com --- Comment #7 from Ben Woodard --- We're hitting this issue over here at LLNL. On 86_64 it was just an annoyance because users who ran into this problem just switched to ICC to work around it. A similar thing happened with the power architecture where the workaround was to use the XL compiler. ARM is making this a higher priority issue for us because there are no vendor compilers to switch to.
[Bug libstdc++/81122] [DR 2381] parsing f stopped after '0' when reading std::hexfloat >> f;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81122 --- Comment #4 from Ben Woodard --- Without this Is there a way to read and write floats and doubles accurately without the rounding that converting to/from base 10 ends up introducing? How are you supposed to use istreams like printf(“%a”,dbl); scanf(“%f, &dbl); Note that scanf does handle doubles in whatever form they come in. Further note that according to stackexchange this works on llvm and other libstdc++ implementations. Therefore if the standard is unclear in this area maybe it is a topic to be clarified.
[Bug libstdc++/81122] [DR 2381] parsing f stopped after '0' when reading std::hexfloat >> f;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81122 --- Comment #5 from Ben Woodard --- The example code in: http://en.cppreference.com/w/cpp/io/manip/fixed suggests that this should work. Probably either the behavior or the library or the example on cppreference should change.
[Bug libstdc++/81122] [DR 2381] parsing f stopped after '0' when reading std::hexfloat >> f;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81122 --- Comment #10 from Ben Woodard --- Also note: https://connect.microsoft.com/VisualStudio/feedback/details/742775 My reading of: https://wg21.link/lwg2381 is that if the first part of the number includes a '.' then the portion after the 'p' or 'P' is not part of the number and is left in the string. The example is 0x1a.bp+07p So I believe that your assertion that 2381 applies in this situation is not accurate. This example refers to the number: 26.6875 (16+10+11/16) and because there is already a hexadecimal point '.' separating the integral portion from the fractional portion the 'p' is not part of the number. However, if the number was: "0x1abp+07p" (note the absence of the '.') then the number would be: in the normal hexfloat format and refer to 1752839.0 leaving the trailing 'p' in the stream.
[Bug libstdc++/81122] [DR 2381] parsing f stopped after '0' when reading std::hexfloat >> f;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81122
--- Comment #15 from Ben Woodard ---
(In reply to Jonathan Wakely from comment #11)
> (In reply to Ben Woodard from comment #10)
> > Also note:
> > https://connect.microsoft.com/VisualStudio/feedback/details/742775
> >
> > My reading of:
> > https://wg21.link/lwg2381
> >
> > is that if the first part of the number includes a '.' then the portion
> > after the 'p' or 'P' is not part of the number and is left in the string.
> > The example is
> > 0x1a.bp+07p
> >
> > So I believe that your assertion that 2381 applies in this situation is not
> > accurate. This example refers to the number: 26.6875 (16+10+11/16) and
> > because there is already a hexadecimal point '.' separating the integral
> > portion from the fractional portion the 'p' is not part of the number.
>
> That just means it's a bad example in the proposed resolution, but the
> example is not normative anyway.
>
> > However, if the number was: "0x1abp+07p" (note the absence of the '.') then
> > the number would be: in the normal hexfloat format and refer to 1752839.0
> > leaving the trailing 'p' in the stream.
>
> But in all versions of the C++ standard the first 'p' is not accumulated in
> Stage 2 of the num_get::do_get call, and so the string passed to strtod is
> "0x1ab" and nothing more. That's what LWG 2381 is about: the list of atoms
> needs to be extended to include 'p' and 'P' so that the fractional portion
> can be accumulated and passed to strtod.
IMHO you have not yet effectively made the case this is related to 2381. Your
assertions are not at all consistent with the text of the change nor have you
explained a couple of other lines of argument that I've presented.
The note specifically says that:
and this is indeed true, for many strings:
assert(is_same("0"));
but not for others
assert(is_same("0xABp-4")); // hex float
These are all strings that are correctly parsed by std::strtod, but not by the
stream extraction operators. They contain characters that are deemed invalid in
stage 2 of parsing.
If we're going to say that we're converting by the rules of strtold, then we
should accept all the things that strtold accepts.
That seems extremely clear to me. What is not clear about that intention?
Never the less since we are in the process of clarifying the standard, I think
that it should be completely obvious that there should be symmetry between
values written using the hexfloat stream modifier should be able to be read in
by the stream.
Logically having the ability to read numbers in . as well
as both normalized non-normalized scientific notation in both decimal and
hexadecimal would be optimal. This would lead six variations of numbers:
100.123
1234.456e89
1.234456E92
0x100.123
0x123.456p90
0xabp-4
of all those the least justifiable would be: 0x123.456p90 because it is a kind
of hybrid of scientific notation and the . numerical
representation and it is probably unlikely that it will ever be used.
Non-normalized scientific notation was sometimes used in some kinds of
engineering where it helped remind people of the precision of the measured
values but I haven't seen it used that way in quite some time and in all the
cases where it was used, it was always decimal rather than hex.
[Bug c++/81812] New: Empty virtual function fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81812
Bug ID: 81812
Summary: Empty virtual function fails to compile
Product: gcc
Version: 7.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: woodard at redhat dot com
Target Milestone: ---
-95 ~]$ cat testg++.C
#include
class Error {
public:
virtual void error( int, int, const char *, ... ) const;
};
void Error::error(int a, int b, const char * c, ...) const {
}
class ChildNode : public virtual Error {
public:
void error( int, int, const char *, ... ) const;
};
void ChildNode::error( int, int, const char *, ... ) const
{
// Uncomment leads to succesful compelation.
//printf("hello world");
}
int main () {}
[ben@li392-95 ~]$ g++ testg++.C -O2 -o testg++
testg++.C:22:14: error: generic thunk code fails for method ‘virtual void
ChildNode::_ZTv0_n24_NK9ChildNode5errorEiiPKcz(int, int, const char*, ...)
const’ which uses ‘...’
int main () {}
^
While if you compile with -O0 it compiles fine.
[Bug c++/81812] Empty virtual function fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81812 --- Comment #2 from Ben Woodard --- Uncommenting the printf allows it to compile. This showed up on F26 x86_64 compiling MRNet
[Bug debug/51358] incorrect/missing location for function arg, -O0, without VTA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51358 --- Comment #13 from Ben Woodard --- This adds some additional complexity to a feature request in https://sourceware.org/bugzilla/show_bug.cgi?id=19949. It would be helpful it were resolved.
[Bug fortran/83254] New: gfortran doesn't consider c_loc addresses c_associated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83254 Bug ID: 83254 Summary: gfortran doesn't consider c_loc addresses c_associated Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: woodard at redhat dot com Target Milestone: --- Created attachment 42776 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42776&action=edit example program gfortran 7.1 -> current trunk doesn't consider c_loc addresses c_associated the way that earlier versions of gfortran does. [ben@localhost cassoc]$ gfortran --version GNU Fortran (GCC) 6.3.1 20170216 (Red Hat 6.3.1-3) Copyright (C) 2016 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. [ben@localhost cassoc]$ gfortran cassoc.f90 -o cassoc.6.3.1 [ben@localhost cassoc]$ ./cassoc.6.3.1 true true but it seems like something broke in the 7 series of compilers. [ben@Mustang c_assoc]$ gfortran --version GNU Fortran (GCC) 7.2.1 20170915 (Red Hat 7.2.1-2) Copyright (C) 2017 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. [ben@Mustang c_assoc]$ gfortran cassoc.f90 [ben@Mustang c_assoc]$ ./a.out true false The original report targeted 7.1 and the problem appears to persist all the way to the current trunk.
[Bug fortran/83254] gfortran doesn't consider c_loc addresses c_associated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83254 --- Comment #2 from Ben Woodard --- my bad my trunk was out of date.
[Bug c/71855] New: duplicate unspecified_parameters DIE in DWARF for functions with variable arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71855 Bug ID: 71855 Summary: duplicate unspecified_parameters DIE in DWARF for functions with variable arguments Product: gcc Version: 6.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: woodard at redhat dot com Target Milestone: --- I was looking at the DWARF generated by GCC 6.1 for M4 and it emits two DIEs for unspecified parameters. Before Dodji added special code to ignore this, it confused libabigail and may confuse other DWARF consumers. [ 1a33]subprogram external (flag_present) name (strp) "m4_error" decl_file(data1) 1 decl_line(data1) 94 prototyped (flag_present) low_pc (addr) 0x00402d10 high_pc (data8) 194 (0x00402dd2) frame_base (exprloc) [ 0] call_frame_cfa GNU_all_call_sites (flag_present) sibling (ref4) [ 1aab] [ 1a50] formal_parameter name (strp) "status" decl_file(data1) 1 decl_line(data1) 94 type (ref4) [58] location (sec_offset) location list [ 78e] [ 1a5f] formal_parameter name (strp) "errnum" decl_file(data1) 1 decl_line(data1) 94 type (ref4) [58] location (sec_offset) location list [ 7c7] [ 1a6e] formal_parameter name (strp) "format" decl_file(data1) 1 decl_line(data1) 94 type (ref4) [d8] location (sec_offset) location list [ 800] [ 1a7d] unspecified_parameters [ 1a7e] variable name (strp) "args" decl_file(data1) 1 decl_line(data1) 96 type (ref4) [ 410] location (exprloc) [ 0] fbreg -216 [ 1a8d] unspecified_parameters [ 1a8e] GNU_call_site low_pc (addr) 0x00402dad abstract_origin (ref4) [ 1fba] [ 1a9b]GNU_call_site_parameter location (exprloc) [ 0] reg8 GNU_call_site_value (exprloc) [ 0] GNU_entry_value: [ 0] reg1 [ 1aa2]GNU_call_site_parameter location (exprloc) [ 0] reg9 GNU_call_site_value (exprloc) [ 0] fbreg -216 See 1a7d 1a8d. This was generated from compiling m4 from ftp://ftp.gnu.org/gnu/m4/m4-1.4.17.tar.gz with GCC 6.1 I will work on making a smaller reproducer.
[Bug c/71855] duplicate unspecified_parameters DIE in DWARF for functions with variable arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71855 --- Comment #1 from Ben Woodard --- I just discovered (by mistake) that the problem does not seem to happen with GCC 4.4.7.
[Bug c/71855] duplicate unspecified_parameters DIE in DWARF for functions with variable arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71855
--- Comment #2 from Ben Woodard ---
This is about as simple of a reproducer as I have been able to come up with:
#define _GNU_SOURCE
#include
#include
#include
void
m4_error (int status, int errnum, const char *format, ...)
{
va_list args;
char *result;
va_start (args, format);
vasprintf (&result, format, args);
va_end (args);
}
[Bug libgcc/109054] New: _Unwind_GetLanguageSpecificData should have protected visibility
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109054 Bug ID: 109054 Summary: _Unwind_GetLanguageSpecificData should have protected visibility Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: woodard at redhat dot com Target Milestone: --- When you look at libgcc_s.so's implementation of _Unwind_GetLanguageSpecificData $ eu-readelf -s /lib64/libgcc_s.so.1 | grep _Unwind_GetLanguageSpecificData 67: 00014d20 12 FUNCGLOBAL DEFAULT 14 _Unwind_GetLanguageSpecificData@@GCC_3.0 It has default visibility. Yes I know that a library should not export functions that are _[A-Z] because those are reserved for system libraries. ref: http://eel.is/c++draft/lex.name#3.1 However, libunwind does and this led to a very hard to track down problem when they had linked an application a particular way. What happened was libgcc_s.so picked up libunwind's implementation of _Unwind_GetLanguageSpecificData this ultimately caused libgcc_s.so to not be able to find the LSDA of an object throwing an exception. This made it so that there was no way to catch the exception and therefore the application aborted. The application was not even aware of the fact that they were using libunwind becasue it came in as a dependency of libzmq. I can't think of a good reason why libgcc_s.so should allow another library to replace its version of _Unwind_GetLanguageSpecificData and so it seems to me that the symbol's visibility should be made protected rather than having the default visibility. Other related bugs are: https://bugzilla.redhat.com/show_bug.cgi?id=2175966
[Bug libgcc/109054] _Unwind_GetLanguageSpecificData should have protected visibility
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109054 --- Comment #3 from Ben Woodard --- Actually what we were hoping to achieve was not to substitute another version of _Unwind_GetLanguageSpecificData for the one that is in libgcc_s.so but rather to make it so that that another implementation of the function couldn't replace the specialized one that is currently in libgcc_s.so The problem that I ran into was that a library that an application was using libzmq from zeromq had a dependency on libunwind. Because of the loading order, this libunwind was loaded before libgcc_s.so and so the dynamic loader found the _Unwind_GetLanguageSpecificData in libunwind before it looked in libgcc_s.so this broke C++ exception handling. What I was hoping could be done is that libgcc_s.so could be forced to ALWAYS use its own version of _Unwind_GetLanguageSpecificData rather than one found in another library like libunwind. Regarding: "Though, I wonder how can unwinding work properly even if we did that. Because e.g. libstdc++.so.6 (or libsupc++.a) C++ EH personality routine calls various _Unwind_* APIs too, including _Unwind_GetLanguageSpecificData, _Unwind_GetGR, _Unwind_GetIP*, _Unwind_GetRegionStart, so if it gets some subset of those symbols from a different unwinder, it can't work correctly." I can authoritatively state that it doesn't work at least on RHEL8 on ppc64le. Maybe making it "protected" visibility is the wrong solution. If there is a way to make it so that libsupc++ or libstdc++'s C++ EH personality routine could be made to only call its own routines rather than ones coming from a different library that would resolve the problem that we have run into. Is there another way to make this happen since all these functions need to be used together as a cohort and cannot be mixed and matched.
[Bug libgcc/109054] _Unwind_GetLanguageSpecificData should have protected visibility
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109054 Ben Woodard changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #5 from Ben Woodard --- good enough
[Bug debug/102523] New: Assume -fvar-tracking -fvar-tracking-assignments when compiling with -O0 -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102523 Bug ID: 102523 Summary: Assume -fvar-tracking -fvar-tracking-assignments when compiling with -O0 -g Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: woodard at redhat dot com Target Milestone: --- One problem that I have run into over and over with developers that I support is they think that -O0 will generate the easiest to debug code. I've been trying to educate them to use -Og but the issue comes up over and over and over again. I have two proposals which could help this problem and improve GCC's usability and reduce the time that those of us who support developers must spend educating people: When the compiler flags include "-O0" and "-g" print out a warning along the lines of: "GCC Warning: debug information will be degraded by the disabling all optimization passes. Consider -Og instead." However, many people never see warnings another proposal is when -O0 and -g are both specified automatically assume -fvar-tracking -fvar-tracking-assignments That would minimize the number of problems that people run into. Either approach would be an improvement in GCC's usability and help avoid a trap that far too many developers seem to fall into.
[Bug debug/102534] New: RFE epilog is not reliably a statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102534
Bug ID: 102534
Summary: RFE epilog is not reliably a statement
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: woodard at redhat dot com
Target Milestone: ---
Created attachment 51523
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51523&action=edit
demonstration program
Given a program like this:
1 #include
2
3 static void do_print(char *s)
4 {
5 printf("%s", s);
6 }
7
8 int main(int argc, char *argv[])
9 {
10 int i = 0;
11 for (;;) {
12do_print(argv[i]);
13i++;
14if (argv[i] == NULL) {
15 do_print("\n");
16 return 0;
17}
18do_print(", ");
19 }
20 #ifdef BAD_MATT_CODE
21 //no longer used
22 return -1;
23 }
24 #endif
25 }
26
27 /**
28 * Just a comment taking a few lines of code
29 * What do you call cheese that isn't yours?
30 * Nacho cheese.
31 **/
32 int unused_variable;
33
34 void unused_function()
35 {
36 printf("I'm not called anywhere\n");
37 }
When you try to set a breakpoint on the closing brace of a function, it skips
to the beginning of the next function in the file:
$ gdb a.out
GNU gdb (GDB) Fedora 10.2-3.fc34
Reading symbols from a.out...
(gdb) break 6
Breakpoint 1 at 0x401060: file line-range.c, line 9.
That is the start of main() which is not what was intended which I would assert
means “break before you leave the context of do_print()” in other words the
epilog of the function.
On the other hand “b 5” works as expected
(gdb) break 5
Breakpoint 2 at 0x401070: /home/ben/Shared/test/line-ranges/line-range.c:5. (3
locations)
(gdb) info break
Num Type Disp Enb AddressWhat
1 breakpoint keep y 0x00401060 in main at line-range.c:9
2 breakpoint keep y
2.1 y 0x00401070 in do_print at
line-range.c:5
2.2 y 0x00401081 in do_print at
line-range.c:5
2.3 y 0x0040109a in do_print at
line-range.c:5
In that particular case the function ends up being inlined and the "ret"
instruction where the epilog is_stmt would be has been eliminated. We believe
it should still mark the first instruction after the code from the function.
Where their would have been a ret.
It isn't just inline functions are affected.
(gdb) break 25
Breakpoint 1 at 0x4011a0: file line-range.c, line 35.
Once again this the first instruction of the function defined after the one
where the epilog for main should be. There is even a ret instruction there:
(gdb) disassemble main
Dump of assembler code for function main:
0x00401060 <+0>: push %rbx
0x00401061 <+1>: mov%rsi,%rbx
0x00401064 <+4>: jmp0x401081
0x00401066 <+6>: nopw %cs:0x0(%rax,%rax,1)
0x00401070 <+16>:mov$0x402013,%esi
0x00401075 <+21>:mov$0x402010,%edi
0x0040107a <+26>:xor%eax,%eax
0x0040107c <+28>:call 0x401050
0x00401081 <+33>:mov(%rbx),%rsi
0x00401084 <+36>:xor%eax,%eax
0x00401086 <+38>:mov$0x402010,%edi
0x0040108b <+43>:add$0x8,%rbx
0x0040108f <+47>:call 0x401050
0x00401094 <+52>:cmpq $0x0,(%rbx)
0x00401098 <+56>:jne0x401070
0x0040109a <+58>:mov$0xa,%edi
0x0040109f <+63>:call 0x401030
0x004010a4 <+68>:xor%eax,%eax
0x004010a6 <+70>:pop%rbx
0x004010a7 <+71>:ret
End of assembler dump.
it even has linemap entries
$ readelf --debug-dump=decodedline a.out | egrep ^File\|25
File nameLine numberStarting addressView
Stmt
line-range.c 250x4010a4 2
line-range.c 250x4010a8
But the problem seems to be that none of the linemap entries is adorned with
is_stmt. We believe that that should point at 4010a7.
Putting the is-stmt for the closing brace of a functopm on the ret instruction
of normal extern function is easy but we would like all the other complicating
situations to be handled as well some of which include:
- inline functions
- void functions
- multiple returns from a
[Bug debug/102534] RFE epilog is not reliably a statement with inlining
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102534 --- Comment #4 from Ben Woodard --- There continues to be an instruction after the completion of the inlining, the next instruction in the sequence, At the time when the inlining occurs why can’t the .loc 1 6 1 be placed there as part of the process of folding the instructions for the inlined code into the calling function. This is analogous to the placement of loc 1 5 4 for the first first line inside the function in every location where the the function is called. It just gets attached to the next instruction after the function’s completion. In other words we argue that .loc 1 6 1 should be attached to the instructions at: 401081 401094 4010a4 Another case that we would like to see work even though it optimizes to no machine instructions which we tried to include in this fragment of source is the case where we call a function that gets completely optimized away to a call for another function. Even when that happens, we would like the residue of its former existence to be in the line map matrix. That is why we included both a static and a potentially external function, were this to be compiled as PIE then the unused function could still be called. We thought that the two situations while highly related, were different. Also you didn’t explain why the main() function at line 25 did not get a breakpoint associated with the closing brace for it. It does have a ret instruction and it is not inlined. If that needs to be a separate PR, I do not mind splitting it off.
[Bug debug/109346] New: RFE add DW_AT_location to DW_TAG_subprogram
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109346 Bug ID: 109346 Summary: RFE add DW_AT_location to DW_TAG_subprogram Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: woodard at redhat dot com Target Milestone: --- There is a currently an issue filed against the DWARF5 standard that asks for DW_AT_location to be the DW_TAG_subprogram and DW_TAG_inlined_subprogram. https://dwarfstd.org/issues/221105.1.html At least for DW_TAG_subprogram the issue seems to have fairly widespread support. Due to the general permissiveness of the DWARF standard, I have found no place in the DWARF5 standard where it says that you can't do this currently even without a textual change in the future DWARF6 standard. In addition to the reasons listed in the DWARF issue, there are a some additional reasons to have it. First of all there is DW_AT_GNU_vector. Because there is ambiguity in the calling convention for array types vs vector types, DW_AT_GNU_vector is required so that GDB can infer using the platform standard ABI where the return value of a function would be located. This is discussed here: https://lists.dwarfstd.org/pipermail/dwarf-discuss/2023-March/002212.html With a location on a DW_AT_subprogram the needs of GDB could be met without DW_AT_GNU_vector. Furthermore, elfutils libdw has the following function which tries to find the location of a function's return value. /* Return location expression to find return value given a DW_TAG_subprogram, DW_TAG_subroutine_type, or similar DIE describing function itself (whose DW_AT_type attribute describes its return type). The given DIE must come from the given module. Returns -1 for errors. Returns zero if the function has no return value (e.g. "void" in C). Otherwise, *LOCOPS gets a location expression to find the return value, and returns the number of operations in the expression. The pointer is permanently allocated at least as long as the module is live. */ extern int dwfl_module_return_value_location (Dwfl_Module *mod, Dwarf_Die *functypedie, const Dwarf_Op **locops); This currently requires a libebl backend for the architecture that knows the standard ABI for the particular return type. And it would indeed give the wrong answer currently if the function doesn't follow the standard calling convention. The problem is with the increasing use of LTO, particularly within GNU/Linux distros,the number of places where this function cannot correctly determine the location of the return value is greatly increased. This is also true for static functions, since programmers are being taught to be more careful with their exported interfaces and they recognize the performance advantages given by optimization passes that use a non-standard calling convention for static functions the number of static functions is increasing. The only really contested point of the proposal is what to do about DW_TAG_inlined_subprogram. However, not adding DW_AT_location to DW_TAG_inlined_subprogram would just be a quality of implementation issue and so it could be omitted for the time being. How to add the location information is not disputed but whether it would be possible for the compiler to correctly emit it, and how much additional DWARF would be required to implement that feature. It would end up being a huge location list for all the places where the inlined subprogram is called. For the moment, I think everyone would be happy if DW_AT_location were just applied to DW_TAG_subprogram and DW_TAG_inlined_subprogram were skipped.
[Bug target/102027] [11/12/13/14 Regression] ABI break when using vector type in function arg/return value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102027 --- Comment #10 from Ben Woodard --- Currently Libabigail is not able to detect this kind of ABI break. We would be able to detect this if https://dwarfstd.org/issues/221105.1.html were implemented. As mentioned in the DWARF issue, this would also other languages and may even simplify some work that debuggers need to do. Since it is just an ignorable attribute, can we start supporting it even before it is standardized.
