#68 BUGFIX: Memory alloc bug in link/z80/lklibr.c

closed-accepted
None
5
2006-10-29
2006-08-07
No

There's a nasty bug on line 289 of
sdcc/link/z80/lklibr.c -- a memory buffer is allocated
for a string, but that buffer is one byte too small and
the trailing null ends up clobbering other memory. This
causes a segfault to occur later in the code.

The fix adds 1 to the buffer length to account for the
trailing null.

This bug was first detected on version 2.6.0, but I
think it might also exist in earlier versions.

Discussion

  • Borut Ražem

    Borut Ražem - 2006-08-08

    Logged In: YES
    user_id=568035

    Bug is already fixed in as/mcs51/lklibr.c and
    as/hc08/lklibr.c. Probably the link/z80/lklibr.c should be
    synchronized with (one of) them.

    Borut

     
  • Frieder Ferlemann

    Logged In: YES
    user_id=589052

    > Probably the link/z80/lklibr.c should be synchronized with
    (one of) them.

    should synchronization be done by hand, by an #include
    "../mcs51/lklibr.c" or would a symbolic link be portable enough?

    A similar synchronization problem also exists for library
    files. Could files like "device/lib/_strlen.c" and
    "device/lib/pic16/libc/string/strlen.c" be unified?

     
  • Maarten Brock

    Maarten Brock - 2006-08-08
    • assigned_to: nobody --> maartenbrock
     
  • Maarten Brock

    Maarten Brock - 2006-08-08

    Logged In: YES
    user_id=888171

    Synchronization should be done either by hand or by
    factoring out the file to a common place. Having the z80
    linker use files in the mcs51 tree seems incorrect to me.
    I'll have a look at it.

    The pic library sources were branched from the normal tree
    on purpose I guess. I don't know why.

     
  • Philip Pemberton

    Logged In: YES
    user_id=386672

    I agree - have a common codebase for the assemblers, then
    have separate subdirectories for the target-specific stuff.
    I'd do something like this:

    asm/src/ - common code
    asm/pic14/src/ - PIC14 assembler code
    asm/mcs51/src/ - 8051 assembler code
    asm/z80/src/ - Z80 and GBZ80 assembler code
    (and so forth)

     
  • Borut Ražem

    Borut Ražem - 2006-08-08

    Logged In: YES
    user_id=568035

    ...and don't forget the hc08 linker in as/hc08!

    I don't understand why the linker code was branched. Why
    should the linker be CPU dependent? GCC has a single linker
    which can link the object files for much more CPUs,
    different languages, object file formats, ...

    I understand that there are some specifics in the debug file
    formats, object file extensions, ..., but they can be
    probably driven by command line options.

    I think it would be optimal to merge all linker code to the
    link/ directory and remove it from as/. But this is probably
    not a trivial think to do and the risk is high :-(

    Borut

     
  • Borut Ražem

    Borut Ražem - 2006-08-08

    Logged In: YES
    user_id=568035

    I thing that the discussin here has gone too far away from
    the original problem.

    Maarten, I saw that you already assigned this bug to
    yourself: I propose to fix only the bug as proposed by
    Philip and open a new feature request for linker
    synchonization / merge / unification.

    Borut

     
  • Maarten Brock

    Maarten Brock - 2006-10-29

    Logged In: YES
    user_id=888171

    Bug fixed.
    Linkers moved to as/link and subdirectories.
    Some common files factored out to as/link itself.

    SDCC 2.6.1 #4442.

     
  • Maarten Brock

    Maarten Brock - 2006-10-29
    • status: open --> closed-accepted
     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks