headers
Joe Orton | 1 Nov 2005 12:53
Picon
Favicon

Re: Debug httpd binaries compiled with --enable-pie with gdb

On Sun, Oct 30, 2005 at 06:47:46PM +0100, Ruediger Pluem wrote:
> On 10/30/2005 06:29 PM, Justin Erenkrantz wrote:
> > 
> > I thought you needed RH-specific patches - that is, no regular
> > (i.e. GNU-stock) version of GDB will support PIE.  -- justin

There's nothing Red Hat specific about PIE, it's all supported in the 
upstream toolchain.

> Thanks for the hint. Meanwhile I downloaded the source RPM of
> 
> http://rpmfind.net/linux/RPM/fedora/updates/3/x86_64/gdb-6.1post-1.20040607.43.x86_64.html
> 
> which compiled fine on RHEL 3. But debugging still does not work :-(.
> I guess the problem now is that my kernel does not give the needed support to gdb as I found
> something about /proc/PID/auxv it tries to use which is not available on my system.

Ah, yeah, there is that too.  The PIE stuff was really only introduced 
in RHEL4 so trying to get this to work on old systems may be hard work.  
The RHEL4 gdb+kernel can happily debug PIE binaries, anyway.

joe
Permalink | Reply | 2 comments |
headers
Ruediger Pluem | 1 Nov 2005 13:05
Picon
Favicon

Re: Debug httpd binaries compiled with --enable-pie with gdb


On 11/01/2005 12:53 PM, Joe Orton wrote:
> On Sun, Oct 30, 2005 at 06:47:46PM +0100, Ruediger Pluem wrote:
> 

[..cut..]

>>
>>which compiled fine on RHEL 3. But debugging still does not work :-(.
>>I guess the problem now is that my kernel does not give the needed support to gdb as I found
>>something about /proc/PID/auxv it tries to use which is not available on my system.
> 
> 
> Ah, yeah, there is that too.  The PIE stuff was really only introduced 
> in RHEL4 so trying to get this to work on old systems may be hard work.  
> The RHEL4 gdb+kernel can happily debug PIE binaries, anyway.

Ok. So I guess I will continue to work with my PIE binaries on RHEL3 without the possibility
to debug them with gdb and will wait for the introduction of RHEL4 in my company to get this
fixed. Thanks for feedback.
Do you think I should add an hint to the debugging page that RHEL3 + --enable-pie + gdb does
not work out of the box?

Regards

Rüdiger
Permalink | Reply | 1 comment |
headers
Joe Orton | 1 Nov 2005 13:19
Picon
Favicon

Re: Debug httpd binaries compiled with --enable-pie with gdb

On Tue, Nov 01, 2005 at 01:05:09PM +0100, Ruediger Pluem wrote:
> Do you think I should add an hint to the debugging page that RHEL3 + --enable-pie + gdb does
> not work out of the box?

I'll add some text, good idea.

joe
Permalink | Reply | 0 comments |
headers
Jim Jagielski | 1 Nov 2005 14:05
Favicon

Re: svn commit: r329849 - in /httpd/httpd/trunk: CHANGES modules/proxy/proxy_util.c

I wanted to avoid making string copies when possible. Plus, we
don't want to lowercase the URL, since that means /Foo/bar
would be the same as /FOO/Bar, which is wrong :)

Ruediger Pluem wrote:
> 
> 
> 
> On 10/31/2005 05:31 PM, jim <at> apache.org wrote:
> > Author: jim
> > Date: Mon Oct 31 08:31:29 2005
> > New Revision: 329849
> > 
> > URL: http://svn.apache.org/viewcvs?rev=329849&view=rev
> > Log:
> > Fix a problem where we are doing a case insensitive
> > match between the worker and the URL. Instead, only
> > the scheme and hostname are insensitive, the rest
> > should be case sensitive.
> > 
> > Modified:
> >     httpd/httpd/trunk/CHANGES
> >     httpd/httpd/trunk/modules/proxy/proxy_util.c
> 
> 
> Thanks for looking into this. I think this is also related to PR36906.
> 
> Given the fact that the hostname and the schema already get lowercased by
> ap_proxy_add_worker, wouldn't it be faster and clearer to do something like
> the following (honest question, I do not know the answer and the best code should
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ruediger Pluem | 1 Nov 2005 14:20
Picon
Favicon

Re: svn commit: r329849 - in /httpd/httpd/trunk: CHANGES modules/proxy/proxy_util.c


On 11/01/2005 02:05 PM, Jim Jagielski wrote:
> I wanted to avoid making string copies when possible. Plus, we

Ok. That was one point of my question as I saw the need to copy the
string as a drawback compared to your approach. I was only unsure how
much this counts.

> don't want to lowercase the URL, since that means /Foo/bar
> would be the same as /FOO/Bar, which is wrong :)

Sure, but I actually do not do this. I only lowercase scheme and hostname, because
I temporarily terminate my copied string with \0 before I lower case it. So from
the functional point of view my approach should do the same as yours. The question
was more about which solution

- is faster
- is more easy to understand if both versions are equally fast

Regards

Rüdiger

[..cut..]
Permalink | Reply | 0 comments |
headers
Jim Jagielski | 1 Nov 2005 14:27
Favicon

Re: svn commit: r329849 - in /httpd/httpd/trunk: CHANGES modules/proxy/proxy_util.c

Since this happens for each request, doing a string copy seems
wasteful to me; it's extra overhead that is avoided with the
current impl. Instead, we have an extra assignment and
check, which is less expensive.

I originally toyed with doing the string copy, but instead
opted for a more pointer oriented solution.

Ruediger Pluem wrote:
> 
> 
> 
> On 11/01/2005 02:05 PM, Jim Jagielski wrote:
> > I wanted to avoid making string copies when possible. Plus, we
> 
> Ok. That was one point of my question as I saw the need to copy the
> string as a drawback compared to your approach. I was only unsure how
> much this counts.
> 
> > don't want to lowercase the URL, since that means /Foo/bar
> > would be the same as /FOO/Bar, which is wrong :)
> 
> Sure, but I actually do not do this. I only lowercase scheme and hostname, because
> I temporarily terminate my copied string with \0 before I lower case it. So from
> the functional point of view my approach should do the same as yours. The question
> was more about which solution
> 
> - is faster
> - is more easy to understand if both versions are equally fast
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ruediger Pluem | 1 Nov 2005 14:52
Picon
Favicon

Re: svn commit: r329849 - in /httpd/httpd/trunk: CHANGES modules/proxy/proxy_util.c


On 11/01/2005 02:27 PM, Jim Jagielski wrote:
> Since this happens for each request, doing a string copy seems
> wasteful to me; it's extra overhead that is avoided with the
> current impl. Instead, we have an extra assignment and
> check, which is less expensive.

This is fine. My other approach was born of the idea that we can
replace strncasecmp with strncmp in the loop. Just for interest:
Any idea regarding the difference in performance between both?

Regards

Rüdiger

[..cut..]
Permalink | Reply | 0 comments |
headers
Jim Jagielski | 1 Nov 2005 14:58
Favicon

Re: svn commit: r329849 - in /httpd/httpd/trunk: CHANGES modules/proxy/proxy_util.c

Ruediger Pluem wrote:
> 
> On 11/01/2005 02:27 PM, Jim Jagielski wrote:
> > Since this happens for each request, doing a string copy seems
> > wasteful to me; it's extra overhead that is avoided with the
> > current impl. Instead, we have an extra assignment and
> > check, which is less expensive.
> 
> This is fine. My other approach was born of the idea that we can
> replace strncasecmp with strncmp in the loop. Just for interest:
> Any idea regarding the difference in performance between both?
> 

Certainly strncmp is quicker, since strncasecmp does an auto
tolower on each char. But we are doing that in both cases,
whether we're tolower'ing the string first, or whether we're
doing it at comparison time. So we're not saving anything
really there.

--

-- 
=======================================================================
 Jim Jagielski   [|]   jim <at> jaguNET.com   [|]   http://www.jaguNET.com/
           "If you can dodge a wrench, you can dodge a ball."
Permalink | Reply | 1 comment |
headers
Ruediger Pluem | 1 Nov 2005 15:29
Picon
Favicon

Re: svn commit: r329849 - in /httpd/httpd/trunk: CHANGES modules/proxy/proxy_util.c


On 11/01/2005 02:58 PM, Jim Jagielski wrote:

[..cut..]

> 
> Certainly strncmp is quicker, since strncasecmp does an auto
> tolower on each char. But we are doing that in both cases,
> whether we're tolower'ing the string first, or whether we're
> doing it at comparison time. So we're not saving anything
> really there.

Yes, but lowering explicitly is done *outside* the for loop.
strncasecmp is done *inside* the for loop. So we do this via
strncasecmp multiple times on the same data.

Regards

Rüdiger
Permalink | Reply | 0 comments |
headers
Jim Jagielski | 1 Nov 2005 15:36
Favicon

Re: svn commit: r329849 - in /httpd/httpd/trunk: CHANGES modules/proxy/proxy_util.c

Ruediger Pluem wrote:
> 
> 
> > 
> > Certainly strncmp is quicker, since strncasecmp does an auto
> > tolower on each char. But we are doing that in both cases,
> > whether we're tolower'ing the string first, or whether we're
> > doing it at comparison time. So we're not saving anything
> > really there.
> 
> Yes, but lowering explicitly is done *outside* the for loop.
> strncasecmp is done *inside* the for loop. So we do this via
> strncasecmp multiple times on the same data.
> 

Whatever. Change it then.

--

-- 
=======================================================================
 Jim Jagielski   [|]   jim <at> jaguNET.com   [|]   http://www.jaguNET.com/
           "If you can dodge a wrench, you can dodge a ball."
Permalink | Reply | 0 comments |

Gmane