[Bug libobjc/27466] RFE: Support for libobjc equivalent of std::set_unexpected
--- Comment #2 from rfm at gnu dot org 2008-11-28 15:56 --- Created an attachment (id=16787) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16787&action=view) An implementation of objc_set_unexpected function We really need this function to use native objective-c in GNUstep. The tiny attached patch does what the gnustep-base library needs ... providing a function to set a hanlder to be called if an exception is not caught. Please could you apply it or something similar. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27466
[Bug libobjc/38307] New: Calling of the +initialize method is not completely thread-safe
When the first attempt to use a class is made, the +initialize method is supposed to be called automatically and safely. The current code check to see whether +initialize needs to be called by seeing if the dispatch table is installed. If the table is not installed, it installs the dispatch table and calls +initialize using locking to prevent another thread from trying to do the same thing, but there is a problem ... once the dispatch table for the class has been installed, it is possible for another thread to use the class before +initialize completes (ie before the method has had a chance to set up all the class variables). This is a rare race condition, but when it occurs it's extremely hard to recognise and track down. I think the fix is reasonably straightforward: when this occurs we need to refrain from installing the dispatch table until +initialize has completed, but we must make sure that the initializing thread is able to call methods of the class while it is executing. The obvious way to do this is to set up a copy of the dispatch table and have the method lookup use that copy (but only if locking permits) if there is no installed dispatch table. Upon completion of +initialize, the copy is installed as the normal dispatch table so that all threads can use it. Unfortunately I haven't had time to implement/test such a fix yet. -- Summary: Calling of the +initialize method is not completely thread-safe Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libobjc AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rfm at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38307
[Bug c/38338] New: Compile abort when compiling code which used to work
The compiler aborts wile building the GNUstep base library.
The problem was originally in an objective-c file, but I isolated it to a small
fragment of C code which causes the same failure.
Compiler version is:
Target: i686-pc-linux-gnu
Configured with: ../configure --with-mpfr=/usr/local --enable-shared
--enable-threads=posix --enable-objc-gc --enable-languages=c,c++,objc,obj-c++
Thread model: posix
gcc version 4.4.0 20081128 (experimental) (GCC)
Here is the compiler error message:
.c: In function Äòapply_charÄô:
x.c:12: error: unable to find a register to spill in class ÄòQ_REGSÄô
x.c:12: error: this is the insn:
(insn 3 2 7 2 x.c:9 (set (mem/c/i:QI (plus:SI (reg/f:SI 20 frame)
(const_int -20 [0xffec])) [0 data+0 S1 A8])
(subreg:QI (reg:SI 4 si [63]) 0)) 50 {*movqi_1} (expr_list:REG_DEAD
(reg:SI 4 si [63])
(nil)))
x.c:12: internal compiler error: in spill_failure, at reload1.c:2093
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
Here is the command line to compile the program:
gcc x.c -c -fPIC
Here is the program (x.c):
typedef void(*apply_t)(void);
static char return_char (char data)
{
return data;
}
static void* apply_char(char data)
{
void* args = __builtin_apply_args();
return __builtin_apply((apply_t)return_char, args, sizeof(void*));
}
--
Summary: Compile abort when compiling code which used to work
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rfm at gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38338
[Bug libobjc/27466] RFE: Support for libobjc equivalent of std::set_unexpected
--- Comment #3 from rfm at gnu dot org 2008-12-08 08:29 --- Any news on when this can be done? The path is tiny/trivial, so even though it might be judged low priority I'd have hoped it could be fitted in quickly. -- rfm at gnu dot org changed: What|Removed |Added CC| |rfm at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27466
[Bug libobjc/38307] Calling of the +initialize method is not completely thread-safe
--- Comment #1 from rfm at gnu dot org 2008-12-08 08:39 --- It turns out that solving this bug, even though it's conceptually simple, is quite a lot of work. I have new code to fix it, but it took me a whole day to develop and involves extensive additions and alterations to sendmsg.c (though I tried to keep the existing code unchanged as much as possible). I'm running the new code on my system to see if I can find any problems before I supply a patch, but if there's any interest I can provide a patch earlier for people to test. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38307
[Bug libobjc/27466] RFE: Support for libobjc equivalent of std::set_unexpected
--- Comment #4 from rfm at gnu dot org 2008-12-17 09:36 --- Is anyone monitoring/progressing this bug? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27466
[Bug libobjc/38307] Calling of the +initialize method is not completely thread-safe
--- Comment #2 from rfm at gnu dot org 2009-01-01 15:02 --- Created an attachment (id=17020) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17020&action=view) Patch for sendmsg.c to fix this bug I've been using this patch for a while ... it modifies sendmsg.c to prevent the bug by not installing the new dispatch table until after the initialize method has completed (while still allowing methods called from +initialize to be found). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38307
[Bug libobjc/27466] RFE: Support for libobjc equivalent of std::set_unexpected
--- Comment #5 from rfm at gnu dot org 2009-01-01 15:08 --- I just checked up on this again ... The problem was initially reported two and a half years ago. I supplied a (very very simple) patch to fix it a month ago. Could someone please apply the patch so it gets into the next release? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27466
[Bug objc/94637] New: @selector() broken for selectors containing repeated colons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94637
Bug ID: 94637
Summary: @selector() broken for selectors containing repeated
colons
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: objc
Assignee: unassigned at gcc dot gnu.org
Reporter: rfm at gnu dot org
Target Milestone: ---
The compiler fails to compile legal Objective-C programs which use the
@selector() syntax to send message to objects, if those messages have multiple
parameters and the method does not describe each one.
eg. when given @selector(styleoffsets::) the compiler errors with the
message
error: expected ‘)’ before ‘::’ token
Within @selector() each colon marks the position at which an argument would be
inserted in a method invocation (when a message is sent to an object). It is
therefore not legal for the compiler to consider a pair of colons to be a token
in this context.
In the above example, the method declaration looks like this:
- (void) styleoffsets: (float*)l : (float*)r : (float*)t : (float*)b
: (unsigned int)style;
While imo it would be better coding style to describe parameters as part of the
method name, it's certainly correct/legal objective-c to have multiple
parameters each preceded only by a colon.
A trivial program to demonstrate the bug would be
#include
#include
int main()
{
SEL s = @selector(example::);
printf("%s\n", sel_getName(s));
return 0;
}
This program, if built with the command 'gcc program.m -lobjc' should produce
an a.out which just prints the selector name.
[Bug objc/94638] New: @selector() broken for selectors containing repeated colons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94638
Bug ID: 94638
Summary: @selector() broken for selectors containing repeated
colons
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: objc
Assignee: unassigned at gcc dot gnu.org
Reporter: rfm at gnu dot org
Target Milestone: ---
The compiler fails to compile legal Objective-C programs which use the
@selector() syntax to send message to objects, if those messages have multiple
parameters and the method does not describe each one.
eg. when given @selector(styleoffsets::) the compiler errors with the
message
error: expected ‘)’ before ‘::’ token
Within @selector() each colon marks the position at which an argument would be
inserted in a method invocation (when a message is sent to an object). It is
therefore not legal for the compiler to consider a pair of colons to be a token
in this context.
In the above example, the method declaration looks like this:
- (void) styleoffsets: (float*)l : (float*)r : (float*)t : (float*)b
: (unsigned int)style;
While imo it would be better coding style to describe parameters as part of the
method name, it's certainly correct/legal objective-c to have multiple
parameters each preceded only by a colon.
A trivial program to demonstrate the bug would be
#include
#include
int main()
{
SEL s = @selector(example::);
printf("%s\n", sel_getName(s));
return 0;
}
This program, if built with the command 'gcc program.m -lobjc' should produce
an a.out which just prints the selector name.
[Bug objc/94638] @selector() broken for selectors containing repeated colons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94638 rfm at gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from rfm at gnu dot org --- Resolving as duplicate since I accidentally submitted the same report twice *** This bug has been marked as a duplicate of bug 94637 ***
[Bug objc/94637] @selector() broken for selectors containing repeated colons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94637 --- Comment #1 from rfm at gnu dot org --- *** Bug 94638 has been marked as a duplicate of this bug. ***
[Bug libffi/41908] New: closures fail for some structure arguments containing floats
For a closure, when an argument is a structure containing multiple floats, it seems that all but the first two floats are lost (on my machine they seem to consistently be set to zeros). This is a big problem in GNUstep where we pass NSRect structures (containing four floats), but I managed to reproduce it by changing one of the libffi testsuite files to pass a structure containing four floats. I have reproduced this problem with libffi from the 4.? series of gcc and have also found it with libffi-3.0.9rc3 -- Summary: closures fail for some structure arguments containing floats Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libffi AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rfm at gnu dot org GCC build triplet: x86_64-linux-gnu GCC host triplet: x86_64-linux-gnu GCC target triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41908
[Bug libffi/41908] closures fail for some structure arguments containing floats
--- Comment #1 from rfm at gnu dot org 2009-11-02 15:58 --- Created an attachment (id=18950) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18950&action=view) test code for bug 419087 This is test code adapted from the libffi testsuite ... it could be added as a new regression test. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41908
[Bug libffi/41908] closures fail for some structure arguments containing floats
--- Comment #4 from rfm at gnu dot org 2009-11-12 11:48 --- I'm a bit disappointed at the lack of activity on this bug report. I've been looking at the libffi code myself (though I'm certainly no expert at this low-level stuff) and have come up with two issues: 1. If I edit libffi-3.0.9rc3/src/x86/ffi64.c and comment out the condition || (n == 2 && SSE_CLASS_P (classes[0]) == SSE_CLASS_P (classes[1])) in ffi_closure_unix64_inner() then this bug goes away (and the change does not appear to break anything in the testsuite). Perhaps someone who understands this stuff could look at this and see why this change appears to fix things (and what it might be breaking). 2. In the classify_argument() function in the same file, there is a comment which reads: /* X86_64_X87UP_CLASS should be preceded by X86_64_X87_CLASS. */ This doesn't match what the code does ... perhaps the code needs to be changed to match the comment... classes[i] = X86_64_X87_CLASS; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41908
[Bug libobjc/80393] New: class_replaceMethod() can modify the wrong class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80393
Bug ID: 80393
Summary: class_replaceMethod() can modify the wrong class
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libobjc
Assignee: unassigned at gcc dot gnu.org
Reporter: rfm at gnu dot org
Target Milestone: ---
The current implementation in libobjc is
IMP
class_replaceMethod (Class class_, SEL selector, IMP implementation,
const char *method_types)
{
struct objc_method * method;
if (class_ == Nil || selector == NULL || implementation == NULL
|| method_types == NULL)
return NULL;
method = search_for_method_in_hierarchy (class_, selector);
if (method)
{
return method_setImplementation (method, implementation);
}
else
{
class_addMethod (class_, selector, implementation, method_types);
return NULL;
}
}
The problem is that the call to search_for_method_in_hierarchy() searches not
only the class that we are interested in, but also all its superclasses. So if
the method we are searching for is implemented in one of the superclasses and
not already overridden (which is a common case), the code finds that method and
changes it, resulting in a change to the superclass implementation of the
method (and any other of its subclasses) as well as the class we actually
wanted to change.
The solution would seem to be to use search_for_method_in_list rather than
search_for_method_in_hierarchy.
[Bug libobjc/38307] Calling of the +initialize method is not completely thread-safe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38307 --- Comment #4 from rfm at gnu dot org 2011-03-16 12:43:39 UTC --- I just searched this old bug report up, and found that I'd missed seeing (or forgotten about) the latest response :-( I've been running with my patch for a couple of years without problems, but when I tried David's patch out, practically all my gnustep code simply started crashing on startup ... so there's something wrong there but I haven't had time to see what it might be. However, to address points in the last comment ... > I still have a hard time groking what was intended with the receiver. It all > seems very intertwined and I think there is a more straight forward way to > implement this. I can't argue with that ... it *is* complex :-( > Also, with this patch get_imp fails on class methods. (get_imp also has the > nasty effect of installing the dispatch table without calling +initialize and > the same goes for __objc_responds_to). Very good point ... it hasn't been an issue for me in practice, but that clearly is something which needs to be addressed. However, I'm not sure that's a new bug ... haven't those functions always bypassed +initialize? I'd have to check, but I agree that they really should call +initialize > I'm not to fond of introducing InitializingList as special type. I think > should > be fine with using the existing hash map tables for this. I don't think we > really need to introduce a new type. Do you really think that method dispatch > for partially installed dispatch tables is performance critical? Certainly there's no performance issue with method dispatch in initialize ... it should be rare enough that we can use a really slow implementation. However, we have to build the dispatch table for the class, so it seemed reasonable to use it within the thread calling +initialize even though we don't want to install it for other threads until +initialize has completed. Perhaps we can store the uninstalled dispatch tables in a hash map more simply than using a new type ... that sounds reasonable.
[Bug libobjc/38307] Calling of the +initialize method is not completely thread-safe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38307 --- Comment #6 from rfm at gnu dot org 2011-03-17 06:20:42 UTC --- I spent some hours looking at your code and I like it ... it's certainly clearer than mine. I found three problems which i've fixed on my system: 1. failure to check CLS_ISRESOLV early enough (I added a check at the very start of __objc_install_dtable_for_class, 2. I needed to add a check immediately after installing the dispatch table of the superclass ... in case the +initialize in the superclass had actually initialized the subclass too. In this case we need to return immediately from __objc_install_dtable_for_class rather than trying to install the table again. 3. The +initialize method of class can cause changes to the methods of the class, so the prepared dispatch table can need to be replaced during the executing of +initialize. I added changes for that. I've been working on an old copy of libobjc ... once I can get your patch plus my modifications workng with svn trunk, I'll post a patch against the current runtime code.
[Bug libobjc/38307] Calling of the +initialize method is not completely thread-safe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38307 rfm at gnu dot org changed: What|Removed |Added Attachment #17020|0 |1 is obsolete|| --- Comment #8 from rfm at gnu dot org 2011-03-17 20:21:13 UTC --- Created attachment 23702 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23702 David's patch with a few more fixes and updated for current svn trunk Made it safe to modify class methods during +initialize (eg as done by class clusters adding behaviors in gnustep). Made it safe for superclass +initialize to use the subclass. Simplified message lookup so that get_imp and objc_msg_lookup share common code, reducing the chance of a mistake in this tricky class initialisation process.
[Bug libobjc/48177] New: incorrect registration of typed selectors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48177 Summary: incorrect registration of typed selectors Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libobjc AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@gnu.org In __sel_register_typed_name() we try to avoid registration of duplicate selectors, but the code uses strcmp() to check for selectors with the same type ... unless I'm missing something, it should probably be using sel_typesMatch()
[Bug libobjc/48177] incorrect registration of typed selectors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48177 --- Comment #2 from rfm at gnu dot org 2011-03-18 14:58:10 UTC --- The problem showed up with argframe information in base ... which presumably means that something in base is getting that wrong :-( I wonder, could we have a runtime function to take a type encoding without argframe info, and convert it to one with argframe info using the same algorithm the compiler uses? That would avoid us having to do that for NSMethodSignature in base (and potentially getting it wrong).
[Bug libobjc/48177] incorrect registration of typed selectors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48177 --- Comment #4 from rfm at gnu dot org 2011-03-21 10:08:31 UTC --- The bug did cause proxies to fail ... but I implemented a workaround for that in base, so it's not critical for gnustep once the new base is released (and older versions of base use the old runtime api anyway). As far as argframe stuff goes in base ... it would be nice to be able to remove it ... perhaps we can. It's part of the public API ... but not of the OSX API as far as I know. maybe it could be deprecated and removed soon.
[Bug libobjc/38307] Calling of the +initialize method is not completely thread-safe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38307 rfm at gnu dot org changed: What|Removed |Added Attachment #23702|0 |1 is obsolete|| --- Comment #9 from rfm at gnu dot org 2011-04-03 04:40:27 UTC --- Created attachment 23857 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23857 Revised/improved patch against svn trunk Here's a new version of the patch. This adds support for the new runtime function class_respondsToSelector()which was previously not considered as it was added to the runtime after the original fic for this bug. This patch also fixes a completely unrelated possible bug that class_respondsToSelector() and __objc_responds_to() were not necessarily returning OjC BOOL values (ie could in theory return values other than 0 or 1).
