8:21 a.m.
APPROVE COMMIT 21.5 RECOMMEND 21.4
Thanks very much for this patch, Andrey. Please send your future
XEmacs contributions to xemacs-patches(a)xemacs.org.
Vin, looks to me like this is needed in 21.4 too.
NOTE: This patch has been committed.
21.5 patch:
ChangeLog files diff command: cvs -q diff -U 0
Files affected: src/ChangeLog
Source files diff command: cvs -q diff -uN
Files affected: src/unexelf.c
Index: src/ChangeLog
===================================================================
RCS file: /pack/xemacscvs/XEmacs/xemacs/src/ChangeLog,v
retrieving revision 1.878
diff -u -p -U0 -r1.878 ChangeLog
--- src/ChangeLog 26 Oct 2005 15:14:53 -0000 1.878
+++ src/ChangeLog 29 Oct 2005 07:11:42 -0000
＠＠ -0,0 +1,5 ＠＠
+2005-10-29 Steve Youngs <steve(a)sxemacs.org>
+
+ * unexelf.c (unexec): Fix data types.
+ From: Andrey Slusar <anrays(a)gmail.com>
+
Index: src/unexelf.c
===================================================================
RCS file: /pack/xemacscvs/XEmacs/xemacs/src/unexelf.c,v
retrieving revision 1.19
diff -u -p -u -r1.19 unexelf.c
--- src/unexelf.c 10 Oct 2005 03:16:25 -0000 1.19
+++ src/unexelf.c 29 Oct 2005 07:11:06 -0000
＠＠ -565,8 +565,8 ＠＠ round_up (ElfW(Addr) x, ElfW(Addr) y)
*
*/
int
-unexec (Extbyte *new_name, Extbyte *old_name, unsigned int UNUSED (data_start),
- unsigned int UNUSED (bss_start), unsigned int UNUSED (entry_address))
+unexec (Extbyte *new_name, Extbyte *old_name, uintptr_t UNUSED (data_start),
+ uintptr_t UNUSED (bss_start), uintptr_t UNUSED (entry_address))
{
int new_file, old_file, new_file_size;
--
|---<Steve Youngs>---------------<GnuPG KeyID: A94B3003>---|
| I am Dyslexic of Borg. |
| Fusistance is retile. Your arse will be laminated. |
|------------------------------------<steve(a)sxemacs.org>---|
10:32 a.m.
New subject: [QUERY] [AC21.5R21.4] [CORE (21.5)] Fix data types in unexelf.c
QUERY
SY> APPROVE COMMIT 21.5 RECOMMEND 21.4
SY> Thanks very much for this patch, Andrey. Please send your
SY> future XEmacs contributions to xemacs-patches(a)xemacs.org.
SY> Vin, looks to me like this is needed in 21.4 too.
Uh, just how many ELF platforms has this been tested on? One?
unexec is a legacy technology; we need to avoid breaking working
platforms using it. At least include an appropriate #ifdef.
--
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
11:55 a.m.
New subject: [QUERY] [AC21.5R21.4] [CORE (21.5)] Fix data types in unexelf.c
Mon, 31 Oct 2005 19:32:24 +0900, Stephen J. Turnbull wrote:
SY> APPROVE COMMIT 21.5 RECOMMEND 21.4
SY> Thanks very much for this patch, Andrey. Please send
your
SY> future XEmacs contributions to xemacs-patches(a)xemacs.org.
SY> Vin, looks to me like this is needed in 21.4 too.
Uh, just how many ELF platforms has this been tested on? One?
No, it's tested on the i386, amd64, ia64, sparc64 FreeBSD.
unexec is a legacy technology; we need to avoid breaking working
platforms using it. At least include an appropriate #ifdef.
Please, read the my original message to xemacs-devel list for more
information:
http://article.gmane.org/gmane.emacs.xemacs.beta/20662/match=anrays+gmail...
--
Regards,
Andrey.
6:18 a.m.
New subject: [R21.4] Fix data types in unexelf.c
RECOMMEND 21.4
lisp.h, which is included by unexelf.c, ensures that uintptr_t is
correctly defined.
>>>> "Andrey" == Andrey Slusar
<anrays(a)gmail.com> writes:
SY> Vin, looks to me like this is needed in 21.4 too.
> Uh, just how many ELF platforms has this been tested on? One?
Andrey> No, it's tested on the i386, amd64, ia64, sparc64
Andrey> FreeBSD.
But for you as a FreeBSD developer, that's just another way of saying
"it works for me."
It's more general than a lot of patches we see, but still, it amounts
to a single platform because the most likely problem here will be if
some other OS either doesn't define that type, or defines it in a
non-standard header. So you could test on 100 CPUs and it still would
not tell us about, say, SCO Unix (which I know was still building as
of last year).
It turns out that the issue is moot because unexelf.c #includes
lisp.h, which goes through the necessary gymnastics to ensure that the
uintptr_t type is properly defined. Please try to include that kind
of information in the future. It would save us some time, which is
always nice. From your point of view, it would make it far more
likely that your patches would go through on your reputation alone in
the future, in cases where it's not so easy to prove that it's right.
--
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
7:14 a.m.
New subject: [R21.4] Fix data types in unexelf.c
Arrrgh!! Andrey, you have my apologies. After staring at the
original post for about 10 minutes, I finally saw that this has
nothing to do with FreeBSD, and everything to do with the definition
in unexelf.c being different from the prototype in lisp.h.
RECOMMEND 21.4
lisp.h, which is included by unexelf.c, ensures that uintptr_t is
correctly defined.
--
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
6 p.m.
Steve Youngs <steve(a)sxemacs.org> writes:
APPROVE COMMIT 21.5 RECOMMEND 21.4
Thanks very much for this patch, Andrey. Please send your future
XEmacs contributions to xemacs-patches(a)xemacs.org.
Vin, looks to me like this is needed in 21.4 too.
NOTE: This patch has been committed.
Andrey -
This patch does not apply to 21.4. The Extbyte stuff is a 21.5-ism.
Is this really necessary for 21.4?
Regards,
Vin
6:15 p.m.
Thu, 24 Nov 2005 13:00:45 -0500, you wrote:
Steve Youngs <steve(a)sxemacs.org> writes:
> APPROVE COMMIT 21.5 RECOMMEND 21.4
>
> Thanks very much for this patch, Andrey. Please send your future
> XEmacs contributions to xemacs-patches(a)xemacs.org.
>
> Vin, looks to me like this is needed in 21.4 too.
>
> NOTE: This patch has been committed.
Andrey -
This patch does not apply to 21.4. The Extbyte stuff is a 21.5-ism.
Is this really necessary for 21.4?
No, it's not needed for 21.4 now. It's needed, when add
`#include lisp.h' to unexelf.c. See backport from 21.5:
--8<---------------cut here---------------start------------->8---
Index: src/unexelf.c
===================================================================
RCS file: /pack/xemacscvs/XEmacs/xemacs/src/unexelf.c,v
retrieving revision 1.15.2.2
diff -u -r1.15.2.2 unexelf.c
--- src/unexelf.c 2005/01/11 02:02:38 1.15.2.2
+++ src/unexelf.c 2005/11/01 09:16:06
＠＠ -413,6 +413,7 ＠＠
#define fatal(a, b, c) fprintf (stderr, a, b, c), exit (1)
#else
#include <config.h>
+#include "lisp.h"
extern void fatal (const char *, ...);
#endif
＠＠ -571,11 +572,9 ＠＠
* .data section, and inserting an empty .bss immediately afterwards.
*
*/
-void unexec (char *new_name, char *old_name, unsigned int data_start,
- unsigned int bss_start, unsigned int entry_address);
-void
-unexec (char *new_name, char *old_name, unsigned int data_start,
- unsigned int bss_start, unsigned int entry_address)
+int
+unexec (char *new_name, char *old_name, uintptr_t data_start,
+ uintptr_t bss_start, uintptr_t entry_address)
{
int new_file, old_file, new_file_size;
＠＠ -645,7 +644,7 ＠＠
break;
}
if (old_bss_index == old_file_h->e_shnum)
- fatal ("Can't find .bss in %s.\n", old_name, 0);
+ fatal ("Can't find .bss in %s.\n", old_name);
for (old_sbss_index = 1; old_sbss_index < (int) old_file_h->e_shnum;
old_sbss_index++)
＠＠ -722,7 +721,7 ＠＠
#endif
if ((unsigned) new_bss_addr < (unsigned) old_bss_addr + old_bss_size)
- fatal (".bss shrank when undumping???\n", 0, 0);
+ fatal (".bss shrank when undumping???\n");
/* Set the output file to the right size and mmap it. Set
* pointers to various interesting objects. stat_buf still has
＠＠ -805,7 +804,7 ＠＠
(old_sbss_index == -1
? old_bss_addr
: round_up (old_bss_addr, alignment)))
- fatal ("Program segment above .bss in %s\n", old_name, 0);
+ fatal ("Program segment above .bss in %s\n", old_name);
if (NEW_PROGRAM_H (n).p_type == PT_LOAD
&& (round_up ((NEW_PROGRAM_H (n)).p_vaddr
＠＠ -815,7 +814,7 ＠＠
break;
}
if (n < 0)
- fatal ("Couldn't find segment next to .bss in %s\n", old_name, 0);
+ fatal ("Couldn't find segment next to .bss in %s\n", old_name);
/* Make sure that the size includes any padding before the old .bss
section. */
＠＠ -846,7 +845,7 ＠＠
".data"))
break;
if (old_data_index == old_file_h->e_shnum)
- fatal ("Can't find .data in %s.\n", old_name, 0);
+ fatal ("Can't find .data in %s.\n", old_name);
/* Walk through all section headers, insert the new data2 section right
before the new bss section. */
＠＠ -1188,4 +1187,5 ＠＠
stat_buf.st_mode |= 0111 & ~n;
if (chmod (new_name, stat_buf.st_mode) == -1)
fatal ("Can't chmod (%s): errno %d\n", new_name, errno);
+ return 0;
}
--8<---------------cut here---------------end--------------->8---
--
Regards,
Andrey.
6980
days inactive
7006
days old
6 comments
4 participants
participants (4)
-
Andrey Slusar -
Stephen J. Turnbull -
Steve Youngs -
Vin Shelton