This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Build failure with probe patch


On 02/19/2015 05:37 PM, Jose E. Marchesi wrote:
> 
>     >     > According to:
>     >     > 
>     >     >   <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41874>
>     >     > 
>     >     > This warning has been removed from GCC.  And by looking at the code
>     >     > referenced by it, I don't see anything wrong there.  So I'd say you can
>     >     > ignore this (and probably update your GCC).
>     >     > 
>     >     
>     >     I would like to avoid updating GCC if possible.  I build on old systems
>     >     because some of our customers use old systems.  I don't know if gdb has
>     >     a 'minimal GCC' that it can be compiled with like GCC and some other
>     >     projects have.  I tried changing the definition of 'dof' to be '
>     >     bfd_byte *' instead of 'struct dtrace_dof_hdr *' and then casting it on
>     >     the call to dtrace_process_dof instead of the call to
>     >     bfd_malloc_and_get_section.
>     > 
>     > I think that version would still break the strict aliasing rules, since
>     > `struct dtrace_dof_hdr' does not alias bfd_byte, even if the latter is a
>     > character type.
>     
>     Hmm, I thought that for aliasing, a typedef to char could
>     alias anything, as typedefs don't really create new types?
> 
> Yes, but not the other way around...  it is not allowed to alias a
> character type with a non-character type like in the following call to
> dtrace_process_dof:

Ah, right.

> gdb_byte *buf;
> [...]
> dtrace_process_dof (sect, objfile, probesp, (struct dtrace_dof_hdr *) buf);

Hmm, still, but I think this may be alright.

gdb_bfd_map_section and bfd_get_full_section_contents return
allocated objects, which have no declared type to begin with
(C99 6.5/6, footnote 75).

Then per C99 6.5/6, since the allocated object is never written
through an lvalue with a type that is not a character type, then
the effective type of the object is "simply the type of the
lvalue used for the access."

So it seems to me that casting to struct dtrace_dof_hdr * and then
reading from that lvalue is OK: from that point on, the object
pointed at by BUF has effective type struct dtrace_dof_hdr.

Thanks,
Pedro Alves


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]