Behaviour of __forced_unwind with noexcept
Hi, I'm looking for some clarification of how the __forced_unwind thread cancellation exceptions intersect with noexcept. I've long been a big fan of the __forced_unwind idiom, but now that C++14 is the default since GCC 6.1, and many methods including destructors are implicitly noexcept, using it safely appears to have become a lot more tricky. The closest I've found so far to an "authoritative" statement of the expected behaviour is the comments from Jonathan Wakely here: https://stackoverflow.com/questions/14268080/cancelling-a-thread-that-has-a-mutex-locked-does-not-unlock-the-mutex In particular: "It interacts with noexcept as you'd expect: std::terminate() is called if a __forced_unwind escapes a noexcept function, so noexcept functions are really noexcept, they won't unexpectedly throw some 'special' type" Which does seem logical, but unless I'm missing something this makes it unsafe to perform any operation in a destructor which might cross a cancellation point, unless that destructor is noexcept(false). And since that could be something as simple as logging to stdio and almost impossible to definitely rule out in a future proof way if the destructor does anything non-trivial (like calling functions in a system or other 3rd party library) ... and since the race of catching a cancellation request in such a destructor could be a relatively rare one to lose in a lot of code ... there could be a lot of extant code with new latent 'crasher' bugs when built with GCC 6.1 or later. And/or a lot of people are going to have to go through a lot of code and mark up a lot of methods with noexcept(false). So I'm half-hoping that I am actually missing something here which mitigates that - but if not, is this something we need to give a bit more thought to? (Please keep me cc'd, I'm not currently on this list) Cheers, Ron
Re: Behaviour of __forced_unwind with noexcept
On Mon, Aug 14, 2017 at 06:22:39PM +0100, Jonathan Wakely wrote: > On 13 August 2017 at 19:20, Ron wrote: > > > > Hi, > > > > I'm looking for some clarification of how the __forced_unwind thread > > cancellation exceptions intersect with noexcept. I've long been a > > big fan of the __forced_unwind idiom, but now that C++14 is the default > > since GCC 6.1, and many methods including destructors are implicitly > > noexcept, using it safely appears to have become a lot more tricky. > > > > The closest I've found so far to an "authoritative" statement of the > > expected behaviour is the comments from Jonathan Wakely here: > > > > https://stackoverflow.com/questions/14268080/cancelling-a-thread-that-has-a-mutex-locked-does-not-unlock-the-mutex > > > > In particular: "It interacts with noexcept as you'd expect: > > std::terminate() is called if a __forced_unwind escapes a noexcept > > function, so noexcept functions are really noexcept, they won't > > unexpectedly throw some 'special' type" > > > > Which does seem logical, but unless I'm missing something this makes > > it unsafe to perform any operation in a destructor which might cross > > a cancellation point, unless that destructor is noexcept(false). > > Unfortunately I still think that's true. > > This was also raised in https://gcc.gnu.org/ml/gcc-help/2015-08/msg00040.html Ouch. Had you considered the option of having any scope that is noexcept(true) also be treated as if it was implicitly in a scoped pthread_setcancelstate(PTHREAD_CANCEL_DISABLE), restoring the old state when it leaves that scope? Would it be feasible for the compiler to automatically generate that? For any toolchain which does use the unwinding exceptions extension, that also seems like a logical extension to the noexcept behaviour, since allowing cancellation will otherwise result in an exception and process termination. If people really need cancellation in such scopes, then they can more manageably mark just those noexcept(false). It would need to be done by the compiler, since in user code I can't do that in a destructor in a way that will also protect unwinding members of a class (which may have destructors in code I don't control). I can't even completely mitigate this by just always using -std=c++03 because presumably I'm also exposed to (at least) libstdc++.so being built with the new compiler default of C++14 or later. I'd be really sad to lose the stack unwinding we currently have when a thread is cancelled. I've always known it was an extension (and I'm still a bit surprised it hasn't become part of the official standard), but it is fairly portable in practice. On Linux (or on Debian at least) clang also supports it. It's also supported by gcc on FreeBSD and MacOS (though not by clang there). It's supported by mingw for Windows builds. OpenBSD is currently the only platform I know of where even its gcc toolchain doesn't support this (but they're also missing support for standard locale functionality so it's a special snowflake anyway). It seems that we need to find some way past the status-quo though, because "don't ever use pthread_cancel" is the same as saying that there's no longer any use for the forced_unwind extension. Or that "you can have a pthread_cancel which leaks resources, or none at all". Having a pthread_cancel that only works on cancellation points that aren't noexcept seems like a reasonable compromise and extension to the shortcomings of the standard to me. Am I missing something there which makes that solution not a viable option either? > > And since that could be something as simple as logging to stdio and > > almost impossible to definitely rule out in a future proof way if the > > destructor does anything non-trivial (like calling functions in a > > system or other 3rd party library) ... and since the race of catching > > a cancellation request in such a destructor could be a relatively rare > > one to lose in a lot of code ... there could be a lot of extant code > > with new latent 'crasher' bugs when built with GCC 6.1 or later. > > > > And/or a lot of people are going to have to go through a lot of code > > and mark up a lot of methods with noexcept(false). > > > > > > So I'm half-hoping that I am actually missing something here which > > mitigates that - but if not, is this something we need to give a > > bit more thought to? > > > > (Please keep me cc'd, I'm not currently on this list) > > > > Cheers, > > Ron
Re: Behaviour of __forced_unwind with noexcept
On Tue, Aug 15, 2017 at 01:31:10PM +0200, Richard Biener wrote: > On Tue, Aug 15, 2017 at 1:28 PM, Jonathan Wakely > wrote: > > On 15 August 2017 at 11:24, Richard Biener > > wrote: > >> On Tue, Aug 15, 2017 at 6:44 AM, Ron wrote: > >>> On Mon, Aug 14, 2017 at 06:22:39PM +0100, Jonathan Wakely wrote: > >>>> On 13 August 2017 at 19:20, Ron wrote: > >>>> > > >>>> > Hi, > >>>> > > >>>> > I'm looking for some clarification of how the __forced_unwind thread > >>>> > cancellation exceptions intersect with noexcept. I've long been a > >>>> > big fan of the __forced_unwind idiom, but now that C++14 is the default > >>>> > since GCC 6.1, and many methods including destructors are implicitly > >>>> > noexcept, using it safely appears to have become a lot more tricky. > >>>> > > >>>> > The closest I've found so far to an "authoritative" statement of the > >>>> > expected behaviour is the comments from Jonathan Wakely here: > >>>> > > >>>> > https://stackoverflow.com/questions/14268080/cancelling-a-thread-that-has-a-mutex-locked-does-not-unlock-the-mutex > >>>> > > >>>> > In particular: "It interacts with noexcept as you'd expect: > >>>> > std::terminate() is called if a __forced_unwind escapes a noexcept > >>>> > function, so noexcept functions are really noexcept, they won't > >>>> > unexpectedly throw some 'special' type" > >>>> > > >>>> > Which does seem logical, but unless I'm missing something this makes > >>>> > it unsafe to perform any operation in a destructor which might cross > >>>> > a cancellation point, unless that destructor is noexcept(false). > >>>> > >>>> Unfortunately I still think that's true. > >>>> > >>>> This was also raised in > >>>> https://gcc.gnu.org/ml/gcc-help/2015-08/msg00040.html > >>> > >>> Ouch. Had you considered the option of having any scope that is > >>> noexcept(true) also be treated as if it was implicitly in a scoped > >>> pthread_setcancelstate(PTHREAD_CANCEL_DISABLE), restoring the > >>> old state when it leaves that scope? > >>> > >>> Would it be feasible for the compiler to automatically generate that? > >>> > >>> For any toolchain which does use the unwinding exceptions extension, > >>> that also seems like a logical extension to the noexcept behaviour, > >>> since allowing cancellation will otherwise result in an exception and > >>> process termination. If people really need cancellation in such > >>> scopes, then they can more manageably mark just those noexcept(false). > >>> > >>> > >>> It would need to be done by the compiler, since in user code I can't > >>> do that in a destructor in a way that will also protect unwinding > >>> members of a class (which may have destructors in code I don't > >>> control). > >>> > >>> I can't even completely mitigate this by just always using -std=c++03 > >>> because presumably I'm also exposed to (at least) libstdc++.so being > >>> built with the new compiler default of C++14 or later. > >>> > >>> > >>> I'd be really sad to lose the stack unwinding we currently have when > >>> a thread is cancelled. I've always known it was an extension (and I'm > >>> still a bit surprised it hasn't become part of the official standard), > >>> but it is fairly portable in practice. > >>> > >>> On Linux (or on Debian at least) clang also supports it. It's also > >>> supported by gcc on FreeBSD and MacOS (though not by clang there). > >>> It's supported by mingw for Windows builds. OpenBSD is currently > >>> the only platform I know of where even its gcc toolchain doesn't > >>> support this (but they're also missing support for standard locale > >>> functionality so it's a special snowflake anyway). > >>> > >>> > >>> It seems that we need to find some way past the status-quo though, > >>> because "don't ever use pthread_cancel" is the same as saying that > >>> there's no longer any use for the f
Re: Behaviour of __forced_unwind with noexcept
On Tue, Aug 15, 2017 at 05:39:10PM +0100, Jonathan Wakely wrote: > On 15 August 2017 at 16:21, Ron wrote: > > On Tue, Aug 15, 2017 at 01:31:10PM +0200, Richard Biener wrote: > >> On Tue, Aug 15, 2017 at 1:28 PM, Jonathan Wakely > >> wrote: > >> > On 15 August 2017 at 11:24, Richard Biener > >> > wrote: > >> >> On Tue, Aug 15, 2017 at 6:44 AM, Ron wrote: > >> >>> On Mon, Aug 14, 2017 at 06:22:39PM +0100, Jonathan Wakely wrote: > >> >>>> On 13 August 2017 at 19:20, Ron wrote: > >> >>>> > > >> >>>> > Hi, > >> >>>> > > >> >>>> > I'm looking for some clarification of how the __forced_unwind thread > >> >>>> > cancellation exceptions intersect with noexcept. I've long been a > >> >>>> > big fan of the __forced_unwind idiom, but now that C++14 is the > >> >>>> > default > >> >>>> > since GCC 6.1, and many methods including destructors are implicitly > >> >>>> > noexcept, using it safely appears to have become a lot more tricky. > >> >>>> > > >> >>>> > The closest I've found so far to an "authoritative" statement of the > >> >>>> > expected behaviour is the comments from Jonathan Wakely here: > >> >>>> > > >> >>>> > https://stackoverflow.com/questions/14268080/cancelling-a-thread-that-has-a-mutex-locked-does-not-unlock-the-mutex > >> >>>> > > >> >>>> > In particular: "It interacts with noexcept as you'd expect: > >> >>>> > std::terminate() is called if a __forced_unwind escapes a noexcept > >> >>>> > function, so noexcept functions are really noexcept, they won't > >> >>>> > unexpectedly throw some 'special' type" > >> >>>> > > >> >>>> > Which does seem logical, but unless I'm missing something this makes > >> >>>> > it unsafe to perform any operation in a destructor which might cross > >> >>>> > a cancellation point, unless that destructor is noexcept(false). > >> >>>> > >> >>>> Unfortunately I still think that's true. > >> >>>> > >> >>>> This was also raised in > >> >>>> https://gcc.gnu.org/ml/gcc-help/2015-08/msg00040.html > >> >>> > >> >>> Ouch. Had you considered the option of having any scope that is > >> >>> noexcept(true) also be treated as if it was implicitly in a scoped > >> >>> pthread_setcancelstate(PTHREAD_CANCEL_DISABLE), restoring the > >> >>> old state when it leaves that scope? > >> >>> > >> >>> Would it be feasible for the compiler to automatically generate that? > >> >>> > >> >>> For any toolchain which does use the unwinding exceptions extension, > >> >>> that also seems like a logical extension to the noexcept behaviour, > >> >>> since allowing cancellation will otherwise result in an exception and > >> >>> process termination. If people really need cancellation in such > >> >>> scopes, then they can more manageably mark just those noexcept(false). > >> >>> > >> >>> > >> >>> It would need to be done by the compiler, since in user code I can't > >> >>> do that in a destructor in a way that will also protect unwinding > >> >>> members of a class (which may have destructors in code I don't > >> >>> control). > >> >>> > >> >>> I can't even completely mitigate this by just always using -std=c++03 > >> >>> because presumably I'm also exposed to (at least) libstdc++.so being > >> >>> built with the new compiler default of C++14 or later. > >> >>> > >> >>> > >> >>> I'd be really sad to lose the stack unwinding we currently have when > >> >>> a thread is cancelled. I've always known it was an extension (and I'm > >> >>> still a bit surprised it hasn't become part of the official standard), > >> >>> but it is fairly portable in practice. > >> >>> > >> >>> On Linux (or on Debian at least) c
Re: Behaviour of __forced_unwind with noexcept
On Tue, Aug 15, 2017 at 05:37:21PM +0100, Szabolcs Nagy wrote:
> On 15/08/17 16:47, Richard Biener wrote:
> > On Tue, Aug 15, 2017 at 5:21 PM, Ron wrote:
> >> Is changing the cancellation state really an expensive operation?
> >> Moreso than the checking which I assume already needs to be done for
> >> noexcept to trap errant exceptions?
> >
> > The noexcept checking only needs to happen if an exception is thrown
> > while the pthread cancel state needs to be adjusted whenever we are
> > about to enter/exit such function.
> >
> >> If it really is, I guess we could also have an attribute which declares
> >> a stronger guarantee than noexcept, to claim there are no cancellation
> >> points in that scope, if people have something in a hot path where a few
> >> cycles really matter to them and this protection is not actually needed.
> >> Which could also be an automatic optimisation if the compiler is able to
> >> prove there are no cancellation points?
> >
> > I guess that's possible.
> >
> > I suppose prototyping this would be wrapping all noexcept calls in
> >
> > try { pthread_setcancelstate (PTHREAD_CANCEL_DISABLE, &old); call
> > (); } finally { pthread_setcancelstate (old, &old); }
> >
>
> i think changing the state this way is only valid if call
> itself does not change the state, which we don't know.
That's a fair statement, but we're only talking about doing this in
functions which are declared noexcept.
It already requires the person writing that code to ensure that
no exceptions are thrown (else the process will terminate), and
this extension would additionally require them to ensure that no
cancellation points become active (which is already required now
anyway since that's already directly equivalent to throwing an
exception as things are now).
The only difference is the compiler can do it safely, where trying
to write that explicitly in user code will still leave gaps where
an unwind exception could leak out.
Best Practices
Hi, I am teaching myself C by writing programs. I have some questions about proper practices.. 1) How do I know when to break my program into separate files. I am currently working on a Star Trek program. It has 4 or 5 large functions. They are all in one file. It's only about 900 lines right now. 2) Should I take something that is only used in one place in my program and make it a function on it's own? 3) What should I do if I have a set of functions I use in many of my programs.. for instance, a randomize() for srandom() and random() that reads /dev/random for it's seed. (so far I use it in two program and I have just cut and paste it between) another example would be a whole setup of #define statements that I use to work with ANSI console stuff. (I know I should probably use curses instead.. I am just learning curses) 4) Are global variables really bad? Why? In my star trek program I have two arrays that are used everywhere. They contain "reality". Passing them in to each function would be a problem.
Re: Mapping C code to generated asm code
On Wed, Jan 11, 2006 at 12:03:42PM -0600, Perry Smith wrote: > Is there a way to get some type of debugging output that tells me > what line of C code produced what lines of asm code? How about $TARGET-objdump --disassemble --source? Ron
Mangled Typedef names in GNU 4.1.2 DWARF data?
The GNU 4.1.2 C++ compiler is mangling typedef names to the point that they are
not retrievable from the DWARF data.
For example, the type BASE_UNION is defined as
typedef union
{
char ch;
int iVal;
long IVal;
} BASE_UNION;
The GNU 4.1.2 compiler generates the following DWARF data for this type
<1><1279>: Abbrev Number: 35 (DW_TAG_union_type)
<127a> DW_AT_sibling : <12a8>
<127e> DW_AT_name: $_4
<1282> DW_AT_byte_size : 4
<1283> DW_AT_decl_file : 35
<1284> DW_AT_decl_line : 29
<2><1285>: Abbrev Number: 36 (DW_TAG_member)
<1286> DW_AT_name: ch
<1289> DW_AT_decl_file : 35
<128a> DW_AT_decl_line : 30
<128b> DW_AT_type:
<2><128f>: Abbrev Number: 36 (DW_TAG_member)
<1290> DW_AT_name: iVal
<1295> DW_AT_decl_file : 35
<1296> DW_AT_decl_line : 31
<1297> DW_AT_type:
<2><129b>: Abbrev Number: 36 (DW_TAG_member)
<129c> DW_AT_name: IVal
<12a1> DW_AT_decl_file : 35
<12a2> DW_AT_decl_line : 32
<12a3> DW_AT_type:
Notice that the union name has been changed to "$_4" in DIE <1279>.
The GNU 3.4.4 compiler generates the following DWARF data from the same source
code:
<1><11d0>: Abbrev Number: 27 (DW_TAG_union_type)
DW_AT_sibling : <123f>
DW_AT_name: (indirect string, offset: 0x6e): BASE_UNION
DW_AT_byte_size : 4
DW_AT_decl_file : 3
DW_AT_decl_line : 29
<2><11dc>: Abbrev Number: 28 (DW_TAG_member)
DW_AT_name: ch
DW_AT_decl_file : 3
DW_AT_decl_line : 30
DW_AT_type:
<2><11e6>: Abbrev Number: 28 (DW_TAG_member)
DW_AT_name: iVal
DW_AT_decl_file : 3
DW_AT_decl_line : 31
DW_AT_type:
<2><11f2>: Abbrev Number: 28 (DW_TAG_member)
DW_AT_name: IVal
DW_AT_decl_file : 3
DW_AT_decl_line : 32
DW_AT_type:
<2><11fe>: Abbrev Number: 29 (DW_TAG_subprogram)
DW_AT_sibling : <1219>
DW_AT_name: (indirect string, offset: 0x79): operator=
DW_AT_type: <123f>
DW_AT_artificial : 1
DW_AT_declaration : 1
<3><120d>: Abbrev Number: 9 (DW_TAG_formal_parameter)
DW_AT_type: <1245>
DW_AT_artificial : 1
<3><1213>: Abbrev Number: 10 (DW_TAG_formal_parameter)
DW_AT_type: <124b>
<2><1219>: Abbrev Number: 30 (DW_TAG_subprogram)
DW_AT_sibling : <1230>
DW_AT_name: $_4
DW_AT_artificial : 1
DW_AT_declaration : 1
<3><1224>: Abbrev Number: 9 (DW_TAG_formal_parameter)
DW_AT_type: <1245>
DW_AT_artificial : 1
<3><122a>: Abbrev Number: 10 (DW_TAG_formal_parameter)
DW_AT_type: <124b>
<2><1230>: Abbrev Number: 31 (DW_TAG_subprogram)
DW_AT_name: $_4
DW_AT_artificial : 1
DW_AT_declaration : 1
<3><1237>: Abbrev Number: 9 (DW_TAG_formal_parameter)
DW_AT_type: <1245>
DW_AT_artificial : 1
Notice that DIE <11D0> contains the correct type name. Also notice that
coincidently, DIE <1230> has a constructor with the "$_4" name which was used
as the type name in GNU 4.1.2.
Why is GNU 4.1.2 generating the mangled type name and how do I correct this to
generate the real type name?
Re: Mangled Typedef names in GNU 4.1.2 DWARF data?
The use of anonymous structure does seem to be the problem. I also missed the
fact that the TYPE_DEF DIE is missing from the DWARF data. If the TYPE
_DEF DIE was in the DWARF data, I could still parse the anonymous type.
Do you think the TYPE_DEF DIE should be part of the output? Is this a GNU
bug or just an unsupported feature?
Thanks.
--- On Fri, 1/22/10, Michael Eager wrote:
> From: Michael Eager
> Subject: Re: Mangled Typedef names in GNU 4.1.2 DWARF data?
> To: "Ron Louzon"
> Cc: gcc@gcc.gnu.org
> Date: Friday, January 22, 2010, 4:39 PM
> Ron Louzon wrote:
> > The GNU 4.1.2 C++ compiler is mangling typedef names
> to the point that they are not retrievable from the DWARF
> data.
> >
> > For example, the type BASE_UNION is defined as
> >
> > typedef union
> > {
> > char ch;
> > int iVal;
> > long IVal;
> > } BASE_UNION;
>
> This is an anonymous union which is typedef'ed to
> BASE_UNION.
>
> >
> > The GNU 4.1.2 compiler generates the following DWARF
> data for this type
> >
> > <1><1279>: Abbrev Number: 35
> (DW_TAG_union_type)
> > <127a>
> DW_AT_sibling :
> <12a8>
> > <127e>
> DW_AT_name :
> $_4
> > <1282>
> DW_AT_byte_size :
> 4
> > <1283>
> DW_AT_decl_file :
> 35
> > <1284>
> DW_AT_decl_line :
> 29
>
> This doesn't look correct. The union has no name, so
> DW_AT_name should
> not be present or should be null. From the DWARF v.3
> spec:
>
> 2.15 Identifier Names
>
> Any debugging information entry representing a
> program entity that has been
> given a name may have a DW_AT_name attribute, whose
> value is a string
> representing the name as it appears in the source
> program. A debugging
> information entry containing no name attribute, or
> containing a name attribute
> whose value consists of a name containing a single
> null byte, represents a
> program entity for which no name was given in the
> source.
>
> > <2><1285>: Abbrev Number: 36
> (DW_TAG_member)
> > <1286>
> DW_AT_name :
> ch
> > <1289>
> DW_AT_decl_file :
> 35
> > <128a>
> DW_AT_decl_line :
> 30
> > <128b>
> DW_AT_type :
>
> > <2><128f>: Abbrev Number: 36
> (DW_TAG_member)
> > <1290>
> DW_AT_name :
> iVal
> > <1295>
> DW_AT_decl_file :
> 35
> > <1296>
> DW_AT_decl_line :
> 31
> > <1297>
> DW_AT_type :
>
> > <2><129b>: Abbrev Number: 36
> (DW_TAG_member)
> > <129c>
> DW_AT_name :
> IVal
> > <12a1>
> DW_AT_decl_file :
> 35
> > <12a2>
> DW_AT_decl_line :
> 32
> > <12a3>
> DW_AT_type :
>
> >
> > Notice that the union name has been changed to "$_4"
> in DIE <1279>.
> >
> > The GNU 3.4.4 compiler generates the following DWARF
> data from the same source code:
> >
> > <1><11d0>: Abbrev Number: 27
> (DW_TAG_union_type)
> > DW_AT_sibling
> : <123f>
> > DW_AT_name
> : (indirect string, offset: 0x6e):
> BASE_UNION
> > DW_AT_byte_size :
> 4
> > DW_AT_decl_file :
> 3
> > DW_AT_decl_line :
> 29
>
> This is similarly incorrect. The union has no name.
>
>
> > Why is GNU 4.1.2 generating the mangled type name and
> how do I correct this to generate the real type name?
>
> A better question might by why there is no DW_TAG_typedef
> DIE which looks like
>
> DW_TAG_typedef
>
> DW_AT_name: BASE_UNION
>
> DW_AT_type: <1279>
>
> BTW gcc-4.3.2 generates
>
> DW_AT_name:
>
> which is also incorrect.
>
>
>
> -- Michael eager ea...@eagercon.com
> 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
>
Intermixing powerpc-eabi and powerpc-linux C code
Hi! Does anyone happen to know if it is possible to link (and run) C code compiled with a powerpc-eabi targeted gcc with C code compiled with a powerpc-linux targeted gcc? The resulting program would be run on a PowerPC Linux system (ELDK 4.0). In this case, main() would be compiled by powerpc-linux-gcc while a test driver and all code to be tested would be compiled by powerpc-eabi-gcc. Everything would be linked using powerpc-linux-gcc. The call from Linux-land to eabi-land would not need to pass arguments nor return anything and nothing would need to be shared between the two pieces of code. None of the powerpc-eabi code will depend on any libraries or other external code, it will all be completely self-contained. Thanks! Ron McCall
Re: Intermixing powerpc-eabi and powerpc-linux C code
I guess I should have also mentioned that the resultant program will be run under gdb, with a script setting breakpoints, running, examining variables, etc. --- Paul Brook <[EMAIL PROTECTED]> wrote: > > The call from Linux-land to eabi-land would not > need > > to pass arguments nor return anything and nothing > > would need to be shared between the two pieces of > > code. > > So basically you can replace the whole thing with > sleep(1); and noone would be > any the wiser. > > Paul >
Re: Intermixing powerpc-eabi and powerpc-linux C code
You make a good point about the linker aspect but I was first most concerned about the code generation differences, if any. However, you are absolutely correct! A test is in order. I whipped up a quick test program and was able to successfully compile, link and run it, so it does indeed work! Thanks! On Thu, Jun 01, 2006 at 04:08:14PM -0700, Mike Stump wrote: > This is a linker question, we don't do linkers here. In particular, > the relocs have to be compatible, if you want to do reloc processing. > You can use ld and resolve all the relocs and just slam in the bytes, > but then, you're not using gcc to link per se. > > Why not just try it out and see?
DWARF2 DW_TAG_base_type for void?
Hi, I have some third party code with the following typedef: typedef void VOID; I found in the readelf dump of the .debug_info section that the corresponding DW_TAG_typedef entry had no DW_AT_type attribute (which usually links to a DW_TAG_base_type entry). It seems that gcc does not emit a DW_TAG_base_type entry for void. Is that intentional? In this program there are only DW_TAG_pointer_type entries linking to this DW_TAG_typedef entry. Without the typedef, I would have expected (perhaps naively) that the DW_TAG_pointer_type would link to a DW_TAG_base_type for void (in the case of a void * pointer type). Is that not the case? I am using gcc 4.0.3 and binutils 2.16.1 in case that matters. Just curious. Ron McCall
Re: DWARF2 DW_TAG_base_type for void?
On Wed, Sep 06, 2006 at 07:39:04PM -0400, Daniel Jacobowitz wrote: > Yes, this is the convention we use. > > Void isn't a base type. The DWARF 3 standard way to represent this is > DW_TAG_unspecified_type. OK, thanks! Ron
"Proceedings of the GCC Developers' Summit" now available
Available for download at: http://people.redhat.com/lockhart/.GCC2007-Proceedings.pdf -Ron /**/ Ron Chen Grid Engine Project: http://gridengine.sunsource.net/ http://www.gridengine.info/ /**/ Fussy? Opinionated? Impossible to please? Perfect. Join Yahoo!'s user panel and lay it on us. http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7
