Re: Fwd: Plans for 1.9

[David CARLIER]

Here a Work in Progress diff, here I simply build both static and shared
libraries, maybe Haproxy folks would prefer only one of those but wanted to
give the choice.
the main entry point from haproxy.c then becomes hap_main one which is the
default but in a fuzzer's perspective, it might be preferrable to just
implement what need to be tested (I just started to play with LLVM/Fuzzer
and haproxy and not sure yet if either it will belong to contrib or not
committed at all).

Let me know if I m taking a relatively correct direction for the specific
Haproxy changes.

Thanks.

On 19 February 2018 at 07:46, David CARLIER  wrote:

> Yes in the case of LLVM/fuzzer, it defines main entry point (thus if your
> tests you need to define a function entry point to receive the data) hence
> it is better if haproxy was a library. Now since haproxy always has been
> "monolithic" I was not sure it would appeal :-)
>
> On 19 February 2018 at 07:26, Willy Tarreau  wrote:
>
>> Hi David,
>>
>> On Mon, Feb 12, 2018 at 03:38:15PM +, David CARLIER wrote:
>> > -- Forwarded message --
>> > From: David CARLIER 
>> > Date: 12 February 2018 at 15:37
>> > Subject: Plans for 1.9
>> > To: w...@1wt.eu
>> >
>> >
>> > Was thinking as a contrib work, making haproxy more fuzzer "compliant"
>> > (AFL and LLVM/fuzzer for example) which would mean turning haproxy into
>> a
>> > shared with a separated exe but not sure it would be ever accepted :-).
>>
>> To be honnest, I have absolutely no idea how it works, so I guess you'll
>> have to give a bit more details here. Making a shared lib out of haproxy
>> probably isn't a big deal. Sometimes it's just a matter of renaming main()
>> and linking with -shared. I don't know if that would be compatible with
>> what you need however.
>>
>> Willy
>>
>
>
From 65d5fcd73fcc084df6d779c932176e859d1a9269 Mon Sep 17 00:00:00 2001
From: David Carlier 
Date: Wed, 21 Feb 2018 13:07:48 +
Subject: [PATCH] BUILD/MEDIUM: haproxy : build as libraries

The goal here is simply to build Haproxy as libraries
and a separated executable
---
 Makefile  | 23 ++-
 include/common/main.h | 25 +
 src/haproxy.c |  2 +-
 src/main.c| 43 +++
 4 files changed, 87 insertions(+), 6 deletions(-)
 create mode 100644 include/common/main.h
 create mode 100644 src/main.c

diff --git a/Makefile b/Makefile
index 2acf5028..8e6a3082 100644
--- a/Makefile
+++ b/Makefile
@@ -433,6 +433,8 @@ ifeq ($(VERDATE),)
 VERDATE := $(shell (grep -v '^\$$Format' VERDATE 2>/dev/null || touch VERDATE) | head -n 1 | cut -f1 -d' ' | tr '-' '/')
 endif
 
+VERSIONNUM = $(shell cat VERSION 2>/dev/null | tr -dc '0-9\.')
+
  Build options
 # Do not change these ones, enable USE_* variables instead.
 OPTIONS_CFLAGS  =
@@ -803,7 +805,7 @@ EBTREE_DIR := ebtree
  Global compile options
 VERBOSE_CFLAGS = $(CFLAGS) $(TARGET_CFLAGS) $(SMALL_OPTS) $(DEFINE)
 COPTS  = -Iinclude -I$(EBTREE_DIR) -Wall
-COPTS += $(CFLAGS) $(TARGET_CFLAGS) $(SMALL_OPTS) $(DEFINE) $(SILENT_DEFINE)
+COPTS += $(CFLAGS) -fPIC $(TARGET_CFLAGS) $(SMALL_OPTS) $(DEFINE) $(SILENT_DEFINE)
 COPTS += $(DEBUG) $(OPTIONS_CFLAGS) $(ADDINC)
 
 ifneq ($(VERSION)$(SUBVERS),)
@@ -894,8 +896,19 @@ DEP = $(INCLUDES) .build_opts
 # Used only to force a rebuild if some build options change
 .build_opts: $(shell rm -f .build_opts.new; echo \'$(TARGET) $(BUILD_OPTIONS) $(VERBOSE_CFLAGS)\' > .build_opts.new; if cmp -s .build_opts .build_opts.new; then rm -f .build_opts.new; else mv -f .build_opts.new .build_opts; fi)
 
-haproxy: $(OPTIONS_OBJS) $(EBTREE_OBJS) $(OBJS)
-	$(LD) $(LDFLAGS) -o $@ $^ $(LDOPTS)
+libhaproxy.so.$(VERSIONNUM): $(OPTIONS_OBJS) $(EBTREE_OBJS) $(OBJS)
+	$(CC) $(COPTS) -Wl,-soname,libhaproxy.so -shared -o libhaproxy.so.$(VERSIONNUM) \
+	$(OPTIONS_OBJS) $(EBTREE_OBJS) $(OBJS) $(LDOPTS) $(LDFLAGS)
+	ln -s libhaproxy.so.$(VERSIONNUM) libhaproxy.so
+
+libhaproxy.a: libhaproxy.so.$(VERSIONNUM) $(OPTIONS_OBJS) $(EBTREE_OBJS) $(OBJS)
+	$(AR) rv $@ $^
+
+#haproxy: $(OPTIONS_OBJS) $(EBTREE_OBJS) $(OBJS)
+#	$(LD) $(LDFLAGS) -o $@ $^ $(LDOPTS)
+
+haproxy: libhaproxy.a
+	$(CC) $(COPTS) -o $@ src/main.c -L. -Wl,-rpath,. -lhaproxy $(LDFLAGS) $(LDOPTS)
 
 $(LIB_EBTREE): $(EBTREE_OBJS)
 	$(AR) rv $@ $^
@@ -910,7 +923,7 @@ src/trace.o: src/trace.c $(DEP)
 	$(CC) $(TRACE_COPTS) -c -o $@ $<
 
 src/haproxy.o:	src/haproxy.c $(DEP)
-	$(CC) $(COPTS) \
+	$(CC) $(COPTS) -fPIC \
 	  -DBUILD_TARGET='"$(strip $(TARGET))"' \
 	  -DBUILD_ARCH='"$(strip $(ARCH))"' \
 	  -DBUILD_CPU='"$(strip $(CPU))"' \
@@ -956,7 +969,7 @@ uninstall:
 	rm -f "$(DESTDIR)$(SBINDIR)"/haproxy
 
 clean:
-	rm -f *.[oas] src/*.[oas] ebtree/*.[oas] haproxy test .build_opts .build_opts.new
+	rm -f *.[oas] src/*.[oas] ebtree/*.[oas] haproxy libhaproxy.* test .build_opts .build_opts.new
 	for dir in . src include/* doc ebtree; do 

Re: Fwd: Plans for 1.9

[David CARLIER]

Yes in the case of LLVM/fuzzer, it defines main entry point (thus if your
tests you need to define a function entry point to receive the data) hence
it is better if haproxy was a library. Now since haproxy always has been
"monolithic" I was not sure it would appeal :-)

On 19 February 2018 at 07:26, Willy Tarreau  wrote:

> Hi David,
>
> On Mon, Feb 12, 2018 at 03:38:15PM +, David CARLIER wrote:
> > -- Forwarded message --
> > From: David CARLIER 
> > Date: 12 February 2018 at 15:37
> > Subject: Plans for 1.9
> > To: w...@1wt.eu
> >
> >
> > Was thinking as a contrib work, making haproxy more fuzzer "compliant"
> > (AFL and LLVM/fuzzer for example) which would mean turning haproxy into a
> > shared with a separated exe but not sure it would be ever accepted :-).
>
> To be honnest, I have absolutely no idea how it works, so I guess you'll
> have to give a bit more details here. Making a shared lib out of haproxy
> probably isn't a big deal. Sometimes it's just a matter of renaming main()
> and linking with -shared. I don't know if that would be compatible with
> what you need however.
>
> Willy
>

Re: Fwd: Plans for 1.9

[Willy Tarreau]

Hi David,

On Mon, Feb 12, 2018 at 03:38:15PM +, David CARLIER wrote:
> -- Forwarded message --
> From: David CARLIER 
> Date: 12 February 2018 at 15:37
> Subject: Plans for 1.9
> To: w...@1wt.eu
> 
> 
> Was thinking as a contrib work, making haproxy more fuzzer "compliant"
> (AFL and LLVM/fuzzer for example) which would mean turning haproxy into a
> shared with a separated exe but not sure it would be ever accepted :-).

To be honnest, I have absolutely no idea how it works, so I guess you'll
have to give a bit more details here. Making a shared lib out of haproxy
probably isn't a big deal. Sometimes it's just a matter of renaming main()
and linking with -shared. I don't know if that would be compatible with
what you need however.

Willy

Fwd: Plans for 1.9

[David CARLIER]

-- Forwarded message --
From: David CARLIER 
Date: 12 February 2018 at 15:37
Subject: Plans for 1.9
To: w...@1wt.eu


Was thinking as a contrib work, making haproxy more fuzzer "compliant"
(AFL and LLVM/fuzzer for example) which would mean turning haproxy into a
shared with a separated exe but not sure it would be ever accepted :-).

Kind regards.