Re: Drivers needing releases
On 30/12/11 08:05 , Cyril Brulebois wrote: Alan Coopersmithalan.coopersm...@oracle.com (28/12/2011): Xorg server release candidates, like the recent 1.12 RC 1, tend to get tested more when users can build drivers that work with them. A number of drivers have needed changes to adjust to the changes in the Xserver ABI, and haven't had tarballs/releases made since those changes went in. Yeah, I planned to wait until rc1 goes out to ask for the same thing. :-) On a side note, Peter, should we expect input ABI to be bumped again for 1.12, or are we done with input-related changes? the input ABI should be done, but I won't be able to get driver releases out until early next year. I'm only only sporadically right now, sorry. If you need to, please feel free to create snapshots of the drivers. Cheers, Peter ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Patches for xf86-video-{tdfx,trident,xgi}
Hi,
following patches are required for building on openSUSE and should be
upstreamed.
To keep actual authors dates I do not send them via 'git send-email', but you
can import them also via 'git am'.
JohannesFrom ec0edfb6e5fc9b31fd4a1d89b0eaed7eed6def75 Mon Sep 17 00:00:00 2001
From: Stefan Dirsch sndir...@novell.com
Date: Thu, 30 Jul 2009 11:28:28 +0200
Subject: [PATCH] Fix RPMLINT warning 64bit-portability-issue.
Signed-off-by: Johannes Obermayr johannesoberm...@gmx.de
---
src/tdfx_dri.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/tdfx_dri.c b/src/tdfx_dri.c
index 31a1b43..8198595 100644
--- a/src/tdfx_dri.c
+++ b/src/tdfx_dri.c
@@ -359,7 +359,7 @@ Bool TDFXDRIScreenInit(ScreenPtr pScreen)
pDRIInfo-ddxDriverMajorVersion = TDFX_MAJOR_VERSION;
pDRIInfo-ddxDriverMinorVersion = TDFX_MINOR_VERSION;
pDRIInfo-ddxDriverPatchVersion = TDFX_PATCHLEVEL;
- pDRIInfo-frameBufferPhysicalAddress = pTDFX-LinearAddr[0];
+ pDRIInfo-frameBufferPhysicalAddress = (pointer) pTDFX-LinearAddr[0];
pDRIInfo-frameBufferSize = pTDFX-FbMapSize;
pDRIInfo-frameBufferStride = pTDFX-stride;
pDRIInfo-ddxDrawableTableEntry = TDFX_MAX_DRAWABLES;
--
1.7.7
From 812546bcc888c214acffac25362c98492bab6230 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?R=C3=BCdiger=20Oertel?= r...@suse.de
Date: Thu, 25 Feb 2010 01:11:59 +0100
Subject: [PATCH] Fix warning: control reaches end of non-void function.
Signed-off-by: Johannes Obermayr johannesoberm...@gmx.de
---
src/blade_accel_exa.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/src/blade_accel_exa.c b/src/blade_accel_exa.c
index 3129623..4a75be1 100644
--- a/src/blade_accel_exa.c
+++ b/src/blade_accel_exa.c
@@ -224,6 +224,7 @@ static void Composite(PixmapPtr pDst, int srcX, int srcY, int maskX,
static void DoneComposite(PixmapPtr pDst)
{
+return 0;
}
static int MarkSync(ScreenPtr pScreen)
--
1.7.7
From 529714780887499a1fafe60b7ad45ea4324869d5 Mon Sep 17 00:00:00 2001
From: Johannes Obermayr johannesoberm...@gmx.de
Date: Thu, 3 Nov 2011 23:22:34 +0100
Subject: [PATCH] Fix warning: control reaches end of non-void function.
---
src/vb_i2c.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/src/vb_i2c.c b/src/vb_i2c.c
index 96e26e3..6fc95c9 100755
--- a/src/vb_i2c.c
+++ b/src/vb_i2c.c
@@ -1632,6 +1632,7 @@ BOOLEAN bReadClockLine(PXGI_HW_DEVICE_INFO pHWDE)
return(bReadClockLineFCNT(pHWDE));
else
ErrorF(Error(XGI) : Unkonwn output device! \n);
+ return FALSE;
}
BOOLEAN bReadDataLine(PXGI_HW_DEVICE_INFO pHWDE)
@@ -1644,6 +1645,7 @@ BOOLEAN bReadDataLine(PXGI_HW_DEVICE_INFO pHWDE)
return(bReadDataLineFCNT(pHWDE));
else
ErrorF(Error(XGI) : Unkonwn output device! \n);
+ return FALSE;
}
BOOLEAN bEDIDCheckSum(PUCHAR pjEDIDBuf,ULONG ulBufSize)
@@ -1890,4 +1892,4 @@ BOOLEAN bGetEDID(
PDEBUGI2C(ErrorF(bGetEDID()-return(%d)\n, status == NO_ERROR ? 1:0));
return (status == NO_ERROR);
-}
\ No newline at end of file
+}
--
1.7.7
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Patches for xf86-video-{tdfx,trident,xgi}
From: Johannes Obermayr johannesoberm...@gmx.de Date: Fri, 30 Dec 2011 12:50:18 +0100 --- src/vb_i2c.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/src/vb_i2c.c b/src/vb_i2c.c index 96e26e3..6fc95c9 100755 --- a/src/vb_i2c.c +++ b/src/vb_i2c.c @@ -1632,6 +1632,7 @@ BOOLEAN bReadClockLine(PXGI_HW_DEVICE_INFO pHWDE) return(bReadClockLineFCNT(pHWDE)); else ErrorF(Error(XGI) : Unkonwn output device! \n); + return FALSE; } BOOLEAN bReadDataLine(PXGI_HW_DEVICE_INFO pHWDE) @@ -1644,6 +1645,7 @@ BOOLEAN bReadDataLine(PXGI_HW_DEVICE_INFO pHWDE) return(bReadDataLineFCNT(pHWDE)); else ErrorF(Error(XGI) : Unkonwn output device! \n); + return FALSE; } The indentation is really messed up here. Visually it suggests that the return FALSE is part of the else clause, but there are no curly braces to make it so. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] test: Add unit test for mieq
Jeremy Huddleston jerem...@apple.com (17/10/2011): Signed-off-by: Jeremy Huddleston jerem...@apple.com I've opened https://bugs.freedesktop.org/44315 to track the failure of this check on mips and mipsel. Mraw, KiBi. signature.asc Description: Digital signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Patches for xf86-video-{tdfx,trident,xgi}
Am Freitag, 30. Dezember 2011, 12:21:35 schrieb Daniel Stone:
Hi,
--- a/src/blade_accel_exa.c
+++ b/src/blade_accel_exa.c
@@ -224,6 +224,7 @@ static void Composite(PixmapPtr pDst, int srcX,
int srcY, int maskX,
static void DoneComposite(PixmapPtr pDst)
{
+return 0;
}
static int MarkSync(ScreenPtr pScreen)
... err, DoneComposite is void - perhaps you meant another function?
Cheers,
Daniel
You are right. I prepared the obsolete patch the wrong way:
It was formerly for:
static Bool PrepareAccess(PixmapPtr pPix, int index)
which was removed by
http://cgit.freedesktop.org/xorg/driver/xf86-video-trident/commit/?id=6afbfaf62a2d049fcf289b1dbf32018fd7fdea1c
Because the former patch failed I adapted it and didn't realize that I did it
in wrong function ...
Sorry for wasting your time.
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Patches for xf86-video-{tdfx,trident,xgi}
Am Freitag, 30. Dezember 2011, 13:07:32 schrieben Sie: From: Johannes Obermayr johannesoberm...@gmx.de Date: Fri, 30 Dec 2011 12:50:18 +0100 --- src/vb_i2c.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/src/vb_i2c.c b/src/vb_i2c.c index 96e26e3..6fc95c9 100755 --- a/src/vb_i2c.c +++ b/src/vb_i2c.c @@ -1632,6 +1632,7 @@ BOOLEAN bReadClockLine(PXGI_HW_DEVICE_INFO pHWDE) return(bReadClockLineFCNT(pHWDE)); else ErrorF(Error(XGI) : Unkonwn output device! \n); + return FALSE; } BOOLEAN bReadDataLine(PXGI_HW_DEVICE_INFO pHWDE) @@ -1644,6 +1645,7 @@ BOOLEAN bReadDataLine(PXGI_HW_DEVICE_INFO pHWDE) return(bReadDataLineFCNT(pHWDE)); else ErrorF(Error(XGI) : Unkonwn output device! \n); + return FALSE; } The indentation is really messed up here. Visually it suggests that the return FALSE is part of the else clause, but there are no curly braces to make it so. It is part of the else clause because the functions will end and return sth. if one of the former (else)ifs is true. return FALSE will be reached only if none of the former (else)ifs is true, also the else part will execute. If you add curly braces the warning in gcc will not be fixed. I assume this is because cases are possible (but not here) where one of the (else)ifs does not lead directly to a return. If indentation is really messed up here one tab on each return FALSE can be removed. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xdm] Support reloading xdm through systemd.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11-12-28 10:37 AM, Michał Górny wrote: Signed-off-by: Michał Górny mgo...@gentoo.org --- xdm.service.in | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/xdm.service.in b/xdm.service.in index e782dd9..cf703c6 100644 --- a/xdm.service.in +++ b/xdm.service.in @@ -4,6 +4,7 @@ After=systemd-user-sessions.service [Service] ExecStart=BINDIR/xdm -nodaemon +ExecReload=/bin/kill -HUP $MAINPID /bin/kill works on all platforms? There are 50,000 hits on google about /usr/bin/kill. One of them for Oracle: http://docs.oracle.com/cd/E19082-01/819-2239/kill-1/index.html Type=notify NotifyAccess=all -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7+CPsACgkQubv1WfueyfygAgCg1jObA1iBrKnGoA7X4Zx06WVF 3P0AmwQwcWkxWjL0mPsR9jby5uEzrytc =ai5p -END PGP SIGNATURE- ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xdm] Support reloading xdm through systemd.
Hi, On 30 December 2011 18:54, Gaetan Nadon mems...@videotron.ca wrote: /bin/kill works on all platforms? There are 50,000 hits on google about /usr/bin/kill. One of them for Oracle: No matter, systemd is (very) Linux-only. Cheers, Daniel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xdm] Support reloading xdm through systemd.
On Wed, Dec 28, 2011 at 16:37:34 +0100, Michał Górny wrote: Signed-off-by: Michał Górny mgo...@gentoo.org --- xdm.service.in |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/xdm.service.in b/xdm.service.in index e782dd9..cf703c6 100644 --- a/xdm.service.in +++ b/xdm.service.in @@ -4,6 +4,7 @@ After=systemd-user-sessions.service [Service] ExecStart=BINDIR/xdm -nodaemon +ExecReload=/bin/kill -HUP $MAINPID Type=notify NotifyAccess=all So systemd goes out of its way to not run shell scripts if possible, but it has no way to just use kill(2) to signal a daemon instead of fork+exec /bin/kill? Cheers, Julien ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xdm] Support reloading xdm through systemd.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11-12-30 02:09 PM, Daniel Stone wrote: Hi, On 30 December 2011 18:54, Gaetan Nadon mems...@videotron.ca wrote: /bin/kill works on all platforms? There are 50,000 hits on google about /usr/bin/kill. One of them for Oracle: No matter, systemd is (very) Linux-only. Thanks, I failed to look at the context. Cheers, Daniel -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7+Eu4ACgkQubv1Wfueyfw6bACgiRdmsBVBO8TAUFU5mR1EtNGN e6UAn3XTTiYBGsE/Lhjo3U+quRVqarnD =KhGv -END PGP SIGNATURE- ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH] os: don't ignore failure from dladdr
If dladdr returns 0, don't go and use the returned Dl_info, it may
contain garbage.
X.Org bug#44315 https://bugs.freedesktop.org/show_bug.cgi?id=44315
Reported-and-tested-by: Cyril Brulebois k...@debian.org
Signed-off-by: Julien Cristau jcris...@debian.org
---
os/backtrace.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/os/backtrace.c b/os/backtrace.c
index 58b4b1f..298bf18 100644
--- a/os/backtrace.c
+++ b/os/backtrace.c
@@ -46,7 +46,11 @@ void xorg_backtrace(void)
ErrorF(\nBacktrace:\n);
size = backtrace(array, 64);
for (i = 0; i size; i++) {
- dladdr(array[i], info);
+ int rc = dladdr(array[i], info);
+ if (rc == 0) {
+ ErrorF(%d: ?? [%p]\n, i, array[i]);
+ continue;
+ }
mod = (info.dli_fname *info.dli_fname) ? info.dli_fname : (vdso);
if (info.dli_saddr)
ErrorF(%d: %s (%s+0x%lx) [%p]\n, i, mod,
--
1.7.7.3
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xdm] Support reloading xdm through systemd.
On Fri, 30 Dec 2011 19:09:26 + Daniel Stone dan...@fooishbar.org wrote: On 30 December 2011 18:54, Gaetan Nadon mems...@videotron.ca wrote: /bin/kill works on all platforms? There are 50,000 hits on google about /usr/bin/kill. One of them for Oracle: No matter, systemd is (very) Linux-only. On the other hand, Fedora is supposedly going to move all the executables into /usr any time soon. So that's quite a fair point I'm going to hand over to them. In the meantime, currently the officially supported way of doing this is through calling /bin/kill. Maybe it will become some kind of virtual alias at some point. -- Best regards, Michał Górny signature.asc Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [xproto: PATCH] Xmd.h: amd64-x32 ABI defines sizeof(long) == sizeof (void*) == 4
On Wed, 28 Dec 2011 12:45:03 -0800 Alan Coopersmith alan.coopersm...@oracle.com wrote: On 12/28/11 12:29, Lu, Hongjiu wrote: From: Lu, Hongjiuhongjiu...@intel.com Date: Wed, 28 Dec 2011 14:34:09 + __AMD64__ is defined when 64bit x86 instruction set is used, which is true for x32. The difference is x32 doesn't define __LP64__. Chapter 7, Development Environment, of the AMD64 ABI (the non-x32 version) does not list __LP64__ as a predefined pre-processor symbol. As far as I'm aware, it's just a GCC convention to define __LP64__ for platforms that use the LP64 programming model, and even GCC didn't do so very consistently in the past. __LP64__ isn't the part of x86-64 psABI while GCC always define __LP64__ for 64bit long on x86. I can check if other compilers do the same. In most cases, __amd64__ is checked for 64bit instructions and we have ported those we have found so far to x32 so that we can use one __amd64__ block to support both x32 and x86-64. C code checking __amd64__ mostly does so to find out the size of long pointers. Instructions are usually at the assembly level, not the C code level. It's a very generic tet. Such software is already broken for very popular MSVC compiler (or mingw64-gcc). Looking for __amd64__ in /usr/include things like endianness test and inline gcc assembly pop up most of the time. Aside: Portable software already lives with it (or solves problems the other way). If one needs reliable storage for void* one uses [u]intptr_t. For guaranteed 64bit value one uses [u]int64_t. They are POSIXish, but are easy to reimplement for weird systems. It would make far more sense for x32 to declare it's __i386__ with additional instructions available (much like MMX, SSE, etc.) than to declare that it's __amd64__ with incompatible types. amd64 instruction set is not a superset of i386, otherwise __amd64__ would not exist at all. - amd64 can't address certain small register forms (like %bh) - can't encode many legacy instructions (decimal ones for example: DAA, DAS, etc.) - can't encode many prefixes (ES, SS overrides, etc.). -- Sergei signature.asc Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xdm] Support reloading xdm through systemd.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11-12-30 02:52 PM, Michał Górny wrote: On Fri, 30 Dec 2011 19:09:26 + Daniel Stone dan...@fooishbar.org wrote: On 30 December 2011 18:54, Gaetan Nadon mems...@videotron.ca wrote: /bin/kill works on all platforms? There are 50,000 hits on google about /usr/bin/kill. One of them for Oracle: No matter, systemd is (very) Linux-only. On the other hand, Fedora is supposedly going to move all the executables into /usr any time soon. So that's quite a fair point I'm going to hand over to them. I recall seeing RPM packages with /usr/bin/kill now that you mention it. In the meantime, currently the officially supported way of doing this is through calling /bin/kill. Maybe it will become some kind of virtual alias at some point. Otherwise a lot of things will break. Keep an eye on it. If need be, we can add the usual config piece in configure.ac. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7+HQkACgkQubv1WfueyfyRzQCgo08AHrrpe9DGSFWBwP2IJdkI 9D0AoMIpkQC6vsIiLlW7kjN1hmfRU/NL =drEX -END PGP SIGNATURE- ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xdm] Support reloading xdm through systemd.
On 12/30/11 10:54, Gaetan Nadon wrote: +ExecReload=/bin/kill -HUP $MAINPID /bin/kill works on all platforms? There are 50,000 hits on google about /usr/bin/kill. One of them for Oracle: http://docs.oracle.com/cd/E19082-01/819-2239/kill-1/index.html /bin has been a symlink to /usr/bin on Solaris since Solaris 2.0 in 1992, so even though we deliver all the binaries as /usr/bin/sh, /usr/bin/rm, /usr/bin/kill, etc. the /bin paths work too. Though of course, Daniel's also right, the whole question is moot in the context of what systemd should run, since systemd is only found on a subset of Linux systems, not other platforms. -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: X.org testing with Google Test
On 12/23/2011 04:36 PM, Ian Romanick wrote: On 12/21/2011 08:51 AM, Thomas Voß wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi list, my name is Thomas and I'm a software engineer in quality working for Canonical. Our quality team is currently extending the test coverage of Canonical's upstream projects. To this end, we are developing a number of components for providing a unified testing landscape to developers. One of our focus areas is the headless automated testing of applications and components that interact with the X display server. For many testing scenarios, only a dummy X server without any display capabilities is required and we abstracted/integrated start up and tear down of such a configuration within a Google Test environment that is readily usable by developers (see [1]). Google Test [2] is a unit testing framework tailored towards C and C++. It is lightweight and provides a decent set of functionality for writing unit tests: I'm in favor of gtest. I've just started using it with Mesa, and I have some (unposted) unit tests for the GLX_ARB_create_context patch series that I just posted to the list. * Automatic test registration: Tests are automatically discovered and recognized. That is, no manual maintenance for executing tests is required. * An extensive set of assertion macros is provided. * The XML output is compatible with JUnit's XML dialect and can be integrated easily with continuous integration systems (e.g. Jenkins [3]). * Support for custom test fixtures that unify test setup and cleanup procedures, thus avoiding boiler plate code within the actual test. * Support for custom test environments for bundling problem specific setup and cleanup routines. The big advantage of a test framework like gtest is that the infrastructure makes it easy to write a large number of small, easy to understand (WTF is this testing?), easy to debug (WTF is this failing?) tests. For the work mentioned above, I wrote about 75 tests. It wasn't until I was done that I even realized how many there were. This seems like a good thing. Our extension to Google Test defines a custom test environment and a custom test fixture that take care of starting up and tearing down a dummy xserver environment (environment.h) as well as opening up a display connection (test.h). Moreover, a custom main is included within our extension that extends Google Test's main and makes sure that our dummy X server testing environment is known to the whole test suite. Please see [4] for a usage scenario within utouch-frame and [5] for xorg-gtest's doxygen documentation. As we think that this kind of unified testing architecture might be of interest to a wider developer audience, we would like to bring it to your attention by this mail. The project is currently hosted in cndougla's freedesktop.org place, but we feel a better home would be on freedesktop.org. It looks like a good landing spot would be in xorg/test on the git.freedesktop.org page. Is there a formal process for proposing projects, or should we just create a repository there? Of course, your feedback is highly appreciated. Kind regards, Thomas Hi guys, I'm all for testing frameworks. Would this tie into tinderbox at all? From what I understand, tinderbox just does periodic compiles to make sure builds didn't break but isn't actually a formal test environment. Would this remain completely independent of that? If I'm wrong on tinderbox, please correct me. Matt ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] os: don't ignore failure from dladdr
Reviewed-by: Jeremy Huddleston jerem...@apple.com
On Dec 30, 2011, at 2:41 PM, Julien Cristau wrote:
If dladdr returns 0, don't go and use the returned Dl_info, it may
contain garbage.
X.Org bug#44315 https://bugs.freedesktop.org/show_bug.cgi?id=44315
Reported-and-tested-by: Cyril Brulebois k...@debian.org
Signed-off-by: Julien Cristau jcris...@debian.org
---
os/backtrace.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/os/backtrace.c b/os/backtrace.c
index 58b4b1f..298bf18 100644
--- a/os/backtrace.c
+++ b/os/backtrace.c
@@ -46,7 +46,11 @@ void xorg_backtrace(void)
ErrorF(\nBacktrace:\n);
size = backtrace(array, 64);
for (i = 0; i size; i++) {
- dladdr(array[i], info);
+ int rc = dladdr(array[i], info);
+ if (rc == 0) {
+ ErrorF(%d: ?? [%p]\n, i, array[i]);
+ continue;
+ }
mod = (info.dli_fname *info.dli_fname) ? info.dli_fname : (vdso);
if (info.dli_saddr)
ErrorF(%d: %s (%s+0x%lx) [%p]\n, i, mod,
--
1.7.7.3
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] os: don't ignore failure from dladdr
Julien Cristau jcris...@debian.org (30/12/2011):
If dladdr returns 0, don't go and use the returned Dl_info, it may
contain garbage.
X.Org bug#44315 https://bugs.freedesktop.org/show_bug.cgi?id=44315
Reported-and-tested-by: Cyril Brulebois k...@debian.org
Signed-off-by: Julien Cristau jcris...@debian.org
---
os/backtrace.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/os/backtrace.c b/os/backtrace.c
index 58b4b1f..298bf18 100644
--- a/os/backtrace.c
+++ b/os/backtrace.c
@@ -46,7 +46,11 @@ void xorg_backtrace(void)
ErrorF(\nBacktrace:\n);
size = backtrace(array, 64);
for (i = 0; i size; i++) {
- dladdr(array[i], info);
+ int rc = dladdr(array[i], info);
+ if (rc == 0) {
+ ErrorF(%d: ?? [%p]\n, i, array[i]);
+ continue;
+ }
mod = (info.dli_fname *info.dli_fname) ? info.dli_fname : (vdso);
if (info.dli_saddr)
ErrorF(%d: %s (%s+0x%lx) [%p]\n, i, mod,
--
Reviewed-by: Cyril Brulebois k...@debian.org
I'll probably propose that commit along with the ia64 build fix for a
pull later today.
Mraw,
KiBi.
signature.asc
Description: Digital signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PULL] Build fixes for ia64, mips, and mipsel
Hi Keith. The following changes since commit c065f7b16329e30cb976359e0a807c2adaf50123: Version 1.11.99.2 (1.12 snapshot 2) (2011-12-17 17:22:45 -0800) are available in the git repository at: git://people.freedesktop.org/~kibi/xserver master Cyril Brulebois (1): linux/ia64: Fix regression after domain I/O support code removal. Julien Cristau (1): os: don't ignore failure from dladdr hw/xfree86/common/compiler.h | 19 --- os/backtrace.c |6 +- 2 files changed, 5 insertions(+), 20 deletions(-) Branch based on top of 1.11.99.2, which is what I tested specifically (yay mips over qemu and its build time over 5 hours), but applies to/can be merged into current master trivially. Mraw, KiBi. signature.asc Description: Digital signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Drivers needing releases
Peter Hutterer peter.hutte...@who-t.net (30/12/2011): the input ABI should be done OK, thanks. but I won't be able to get driver releases out until early next year. I'm only only sporadically right now, sorry. If you need to, please feel free to create snapshots of the drivers. I'll start uploading drivers to experimental, and will try and look into snapshots (RCs?) for the drivers which need it. Mraw, KiBi. signature.asc Description: Digital signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
